DOCUMENT RESUME 

HE 021 558 

Leveraging Information Technology* Track II: 
Innovative Management* 
CAUSE, Boulder, Colo* 
88 

73p.; In: Leveraging Information Technology* 
Proceedings of the CAUSE National Conference (Tarpon 
Springs, FL, December 1-4, 1987); see HE 021 556* 
CAUSE Exchange Library, 737 Twenty-Ninth Street, 
Boulder, CO 80303 (Individual papers available for 
cost of reproduction)* 
Speeches/Conference Papers (150) 

MF01/PC03 Plus Postage* 

Budgeting; Committees; Computer Software; ^Computer 
Uses in Education; Decentralization; Higher 
Education; ^Information Technology; Innovation; 
♦Management Information Systems; Microcomputers; 
Private Colleges; Simulation; State Universities; 
Systems Development; Time 

♦CAUSE National Conference; Decision Support Systems; 
Pennsylvania State University; Saint Louis University 
MO; Stanford University CA; University of Akron OH; 
University of British Columbia (Canada); University 
of Missouri; University of South Carolina 



Seven papers from the 1987 CAUSE conference's Track 
II, Innovative Management, are presented* They include: "Is This 
Creative, or What!" (Kenneth C. Blythe); "Joint Application Design: 
Can a User Committee Design a System in Four Days?" (Diane Kent, 
David Smithers); "Making It Happen without Appropriation" (Robert E. 
Robe r son); "Prototypes and Simulations as Decision Tools: Increasing 
the Software Implementation Success Ratio" (Elliott J* Haugen and 
Brian D. Nedwek); "Administrative and Strategic Computing" (Ronald L* 
Moore and Frank B. Thomas); "Stanford Jumps to the '90s — Distributed 
Programming, Promising or Premature?" (David J* Ernst); and "The 
Director Dons the Banker's Cap, or, Need a PC? Have I Got a Deal for 
Tou!" (Arthur Brooks)* (LB) 



******************************************** 

* Reproductions supplied by EDRS are the best that can be made * 

* from the original document* * 
*********************************************************************** 



ED 294 509 
TITLE 

INSTITUTION 
PUB DATE 
NOTE 

AVAILABLE FROM 

PUB TYPE 

EDRS PRICE 
DESCRIPTORS 

IDENTIFIERS 

ABSTRACT 



Leveraging Information 
Technology 

Proceedings of the 
1987 CAUSE National Conference 

TRACK II: Innovative Management. 

December 1-4, 1987 
Innisbrook Resort 

Tarpon Springs, Florida 



U.S. DEPARTMENT OF EDUCATION 

Office of Educational Research and Improvement 

EDUCATIONAL RESOURCES INFORMATION 
CENTER (ERIC) 

OThis document has been reproduced as 
received from the person or organization 
originating it 

O Minor changes have been made to improve 
reproduction quality 



• Points of view or opinions stated in this docu- 
ment do not necessarily represent official 
OERI position or policy. 



"PERMISSION TO REPRODUCE THIS 
MATERIAL HAS BEEN GRANTED BY 



TO THE EDUCATIONAL RESOURCES 
INFORMATION CENTER (ERIC)." 



Copyright© 1988 CAUSE 



CKSE 




CAUSE, the Professional Association for Computing and Information Tech- 
nology in Higher Education, helps colleges and universities strengthen and 
improve their computing, communications, and information services, both 
academic and administrative. The association also helps individual members 
develop as professionals in the field of higher education computing and infor- 
mation technology. 

Formerly known as the College and University Systems Exchange, CAUSE 
was organized as a volunteer association in 1962 and incorporated in 1971 
with twenty-five charter member institutions. In the same year the CAUSE 
National Office opened in JJoulder, Colorado, with a professional staffto serve 
the membership. Today the association serves almost 2,000 individuals from 
730 campuses representing nearly 500 colleges and universities, and 31 
sustaining member companies. 

CAUSE provides member institutions with many services to increase the ef- 
fectiveness of their computing environments, including: the Administrative 
Systems Query (ASQ) Service, which provides to members information about 
typical computing practices among peer institutions from a data base of 
member institution profiles; the CAUSE Exchange Library, a clearinghouse 
for documents and systems descriptions made available by members through 
CAUSE; association publications, including a bi-monthly newsletter, CAUSE 
Information, the professional magazine, CAUSE /EFFECT, and monographs 
and professional papers; workshops and seminars; and the CAUSE National 
Conference. 

We encourage you to use CAUSE to support your own efforts to strengthen 
your institution's management and educational capabilities through the 
effective use of computing and information technology. 



INTRODUCTION 

As professionals in an always-exciting field, we are constantly feeing challenges to blend new infor- 
mation technologies into our institutions* It is important for higher education to develop environ- 
ments that promote the use of information technology for strategic advantages, that allow faculty, 
staff, and students to benefit from existing technology, and that stimulate the discovery of new 
opportunities* 

The 1987 CAUSE National Conference, with its theme "Leveraging Information Technology," offered 
the opportunity for us to share, exchange, and learn of new developments in information technology 
to improve and enhance our environments* The CAUSE87 program was designed to allowLthefizllest 
possible discussion of issues related to these new developments* Seven concurrent tracks with 49 
selected presentations covered important issues in general areas of policy and planning, manage- 
ment, organization, and support services, as well as in the specialized areas of communications, 
hardware/software strategies, and outstanding applications* 

To expand opportunities for informal interaction, some changes were made in the program schedule* 
CAUSE Constituent Groups met the day before the conference, as they did in 1986, but were given 
opportunities to meet again during the conference. Current Issues Sessions were moved to Thursday 
afternoon to provide some flexibility with time, encourage interactive participation, and extend 
opportunities to continue discussions with colleagues* Vendor workshops were offered for the first 
time this year, the day before the conference. The Wednesday afternoon schedule accommodated 
continued vendor workshops, vendor suite exhibits, and concurrent vendor sessions. 

David P. Roselle, President of the University of Kentucky, set the tone for CAUSE8T with a Wednes- 
day morning opening presentation expressing his commitment to the value of information technology 
in higher education. John G. Kemeny, past president of Dartmouth College and currently Chairman 
of the Board of True BASIC, Inc., spoke during Thursday's luncheon of new developments in comput- 
ing for classroom learning. The concluding general session, Friday's Current Issues Forum, offered 
an exchange of philosophies about making optimal use of technologies on our campuses. 

We were extremely fortunate to be at Innisbrook, a resort with outstanding conference facilities and 
great natural beauty (and weather)— a real distillation of the best of Florida. 

Almost 800 people attended CAUSE87. Many of them described the conference, in their evaluation 
forms, as stimulating, informative, and memorable. We hope this publication of the substance of 
CAUSE87 will be a continuing resource, both for conference-goers and for those who will be reading 
about the conference offerings for the first time. 



Wayne Donald 
CAUSE87 Chair 



Leveraging Information Technology 

Table of Contents 



TRACK II: Innovative Management 89 

Is This Creative, or What! 91 

Kenneth C. Blythe 

Joint Application Design: Can a User Committee Design a System in Four Days? 101 

Diane Kent and David Smithers 

Making It Happen without Appropriation Ill 

Robert E. Roberson 

Prototypes and Simulations as Decision Tools: Increasing the Software 

Implementation Success Ratio 123 

Elliott J. Haugen and Brian P. Nedwek 

Administrative and Strategic Computing 133 

Ronald L. Moore and Frank B. Thomas 

Stanford Jumps to the Ws— Distributed Programming, Promising or Premature? 141 

David J. Ernst 

The Director Dons the Banker's Cap, or, Need a PC? Have I Got a Deal for You! 153 

Arthur Brooks 



5 



r 

89 



Track II 

Innovative Management 




Coordinator: 
Carole Barone 
Syracuse University 

Papers in this track describe unusual techniques for acquiring information 
technology, for utilizing the technology to maintain an acceptable level of 
operation, or for innovative management in the academic arena or administra- 
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Is this Creative , or What! 

Kenneth C. Blythe 

The Pennsylvania State University 
University Park, Pennsylvania 



How do we bring innovation to the Administrative computer 
business? Competition demands that we seek new 
technological initiatives that make a difference. New 
systems should not be developed as a matter of rote but as 
a matter of strategic importance. But, how do we do this? 
By recognizing that the most important things are not 
always most apparent. Someone must take leadership and 
explain that traditional, remedies are not always creative 
remedies; that computer specialists can become absorbed in 
minutia and forget the dream. Let's get things on track 
and remember that we harness the most important tool of 
the century for organizational efficiency and effective- 
ness. This paper is a report on innovation in Penn State 
administrative computing. 
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IS THIS CREATIVE, OR WHAT! 



What an exhilaration! Here, at my desk, I can inquire into databases that are in my 
personal computer or in computers that are thousands of miles away. I can inquire 
about census data, health data, student data, financial data ... all within easy reach 
. . .right from my desk. I can visit libraries with millions of volumes, search for 
articles, connect with others who have published before me. I can work at home or 
in the office in a continuum that knows no geographic or time boundary. I can 
collaborate, electronically, with writers and thinkers and managers like myself 
across the nation ... at my desk. What are the limits? Where are the boundaries? 
Only in my mind. 

Is this creative, or what! It is the very essence of creativity. In all of my career 
experiences, none match the creativity that I experience at Pennsylvania State 
University. The University is alive with creative ideas and bold conceptions of the 
application of technology. Examples of this creativity are numerous and I will try to 
touch on a few along the way. But, it is not my purpose to demonstrate Pen n State's 
creativity as much as it is to discover the reasons for it. Just what is creativity and 
how is it activated? 

I submit that the first requirement to activate creativity is to recognize when 
creativity is at work. The relentless pace of change, these days, obscures the 
investment that is made in one change as compared to another. Creative changes 
are absorbed as just another pedestrian, day-to-day occurrence. Is it spectacular 
that thousands of individuals can access a single database simultaneously? No, not 
particularly. Is it amazing that we can transmit electronic mail nationwide? No. 
Once, it was amazing, but no more. And why is this? Because it is the nature of 
creativity that it is creative only once. Then, it becomes prudent. Telephones, for 
example, are not thought to be creative, but they are cr.rtainly prudent. Most 
businesses could not get along without them. This, then, is a clue to the nature of 
creativity. It is a transitory event. We, who are in the business of high technology, 
must recognize that one creative event is not long lasting. It is no longer 
satisfactory to achieve a single creation As the agents of change in our institutions, 
we must seek an environment that produces a continuous stream of innovative 
changes. To quote Warren McFarlan of the Harvard Business School, the 
information systems function is "in tne business of bringing a sustained stream of 
innovation in information services to change the company s internal operations. . . 
and external products." 1 

ART OR SCIENCE 

As long as I can remember, it h^s been debated whether computer programming is 
an art or a science. Is the creation of a computer program analogous to the creation 
of a watercolor painting or cataloging the stars of the universe? The question is 
important because it leads to conclusions about the management of computer 
programming, systems development and technological change, in general. Ignored 
in the debate is the much more fundamental question of creativity. In our quest to 



1 F. Warren McFarlan and Jamas L. McKenney, Corporate Information Systems Management: The 
Issues Facing Senior Executive*, Richard D. Irwin, Homewood, IL 1983 
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categorize technological change we have failed to understand its underlying 
creative nature. Becau> s we conclude that technological change is more 
science-like than art, we tend to focus on "method" rather than "result." We 
"administer data", "initiate projects", "define requirements", "prepare reports", 
"develop programs" in a structured way. Hardly ever do we brainstorm or monitor 
the sources of innovation. Why? Because that is the way we've been taught. 

Believe it or not, the popular conception is that technologists are creators. We are 
thought to hold creative solutions to social progress, efficiency and institutional 
success. Given that this is true, lets qet on with it. Let us understand the factors of 
creativity and how they are applied. 

WHAT IS CREATIVITY 

To define creativity, I will begin with a quote from Herbert Simon : 

"About forty years ago, the Federal Courts put themselves in the position of 
requiring that for an invention to be patentable there must be proof that a 
"spark of genius" had occurred. The language was Mr. Justice Hand's. The 
trouble with sparks of genius, and similar evidences of creativity, is that they are 
not photographable, hence are difficult to introduce a> evidence. As long as we 
refer to acts of creativity with awe and emphasize their unfathomability, we are 
unlikely to achieve an understanding of their processes. Fortunately, it is not 
necessary to surround creativity with mystery and obfuscation...The simplest way 
to find a definition of creativity is to observe when people apply the term 
"creative" to some human act. Acts are judged to be creative when they 
produce something that is novel and that is thought to be interesting or to have 
social value . . . But in the last analysis, each field must make its own judgements 
of creativity; each must decide what is novel and what products are interesting 
or valuable. "2 

Notice that this description does not deny that "spark of genius" is a characteristic 
of creativity but it is not the- only characteristic. Another due to creativity is that it is 
more often the result of hard work, dedication, chance or timing than "spark of 
genius." Thomas Edison tried literally thousands of materials before he came across 
a suitable light bulb filament. He attributed invention to "99% perspiration and 
1% inspiration. "3 

Creativity then is an ACT that produces SOMETHING which is NOVEL and has VALUE. 
The outward sign of creativity is CHANGE. Not any change but novel and valuable 
change. Change far the sake of change is not creative. Change that makes a 
difference is creative because it is novel and has value. 



2 Conference Proceedings Frontiers in Creative and Innovative Management edited by Robert 
Lawrence Kuhn f Ballinger Publishing Company, Cambridge, Massachusetts, 1985 



3 Robert Friedel and Paul Israel, Edison's Electric Light. Rutgers University Press, New Brunswick, 
New Jersey, 1986 



CREATIVE MANAGEMENT 



SOURCES of 
INNOVATION 



AIM 
HIGH 



LOOK, ASK & 
LISTEN 



START OFF 
SMALL <*- 



SIMPUCITY 



FIGURE 1 Principles of Innovation 



Peter Drucker is the best source I have found for instruction in creative 
management. His book, Innovation and Entreoreneurship. 4 explains clearly 

how to be innovative. 
Being innovative (i.e.: 
creative) requires that 
you view your job 
differently. It requires 
personal 

transformation from 
developer to creator. 
Let me explain with an 
example. Figure 1 is 
Drucker's innovation 
model and Figure 2 is 
the traditional systems 
development model. 
Note the difference. 
The traditional model 
begins with PROBLEM 

DEFINITION as 

compared to the 
^ innovation model's 

SOURCES OF INNOVATION. PROBLEM DEFINITION is a narrower objective than 
searcnma. first, for the sources of innovation. Do problems always precede 
innovation? Certainly not. 
As offices of technological 
change, we are on 'tie 
cutting edge of our 
institutions and should 
recognize what we are 
cutting ... red tape, 
partially; inefficiency, 
partially... but more than 
that, we are cutting new 
trails. If we start with a 
narrow, problem solving 
conception we will shackle 
to lowered expectations. 
Forthesakeof our 
institutions, ,ve must seek 
broader opportunities 
rather than problems; 
creations rather than 
solutions. 



DEFINE 
PROBLEM 



MAINTENANCE 



IMPLEMENTATION 



ALTERNATIVE 
SOLUTIONS 



ANALYSIS 
& 

PROGRAMMING 



FIGURE 2 Traditional Model 



4 Peter F - Drucker, Innovation a nd Entreoreneurshi p William Heinemann Ltd, London 
England, 1985 
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THE INNOVATION MODEL 



Using Drucker's model (Figure 1), I will briefly review some innovative activities 
underway at Penn State. Keep in mind that innovative changes are those that are 
novel and have value. For the sake of understanding at Penn State, novel means 
new to Penn State. It does not mean universally noveL Voice response registration, 
for example, is novel at Penn State even though it has already been implemented at 
other institutions. 

Sources of Innovation 

The first step of Drucker'p model is to look for the sources of innovation. Before 
rushing into something with low value, take the time to survey the opportunities to 
innovate. As Drucker explains, "it is change that always provides the opportunity 
for the new and different Systematic innovation therefore consists in the 
purposeful and organized search for changes, and for the systematic analysis of the 
opportunities such change might offer for economic and social innovation. " The 
changes that must be systematically monitored are those shown in Figure 3. 



Sources of innovation 

INTERNAL SOURCES 

• The Unexpected 

• The Incongruity 

• Changes in Process 

• Changes in Structures 

EXTERNAL SOURCES 

• Demographics 

• Social Change 

• New Products or Knowledge 



FIGURE 3 Sources of Innovation 

They are the sources of innovation. Although these sources are all relevant, I will 
focus on is "changes in process/'Changes in process are changes in the way we 
conduct business, structural changes. To systematically search for creative structural 
changes, it is necessary to foster high-level debate and evaluation of the technology 
agenda. High-level officers, i have round, are the primary source of creative 
thinking. At Penn State, the high-level debate commences with strategic planning. 
Once a year, as the head of administrative computing, I prepare an administrative 
computing plan for the following year. This year I also prepared a five year forecast 
of areas of greatest payoff during the next five years. Penn Stated strategic plan is 
not an idle document. It is reviewed by many before it is approved and even then it 
is only partially approved. The strategic plan sets the floor for development 
activities but does not tell the whole story. Beyond the global initiatives of the 
strategic plan, there is continuing discourse on the priorities assigned to day-to-day 
work. This discourse is very creative and generally surfaces projects of greatest 
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urqency and opportunity. The participants are highly placed individuals who have 
anexceilent understanding of Penn State as it compares to other Universities. They 
naturally bring creative, competitive topics to the administrative computing work 
schedule. The key to unlocking creativity is the cultivation of an environment that 
encourages creativity to flow. 

Another source of innovation that we are monitoring at Penn State is com outer 
aided systems engineering or CASE. This area is especially ripe with creative 
opportunities. We are moving into CASE slowly because we want to realize it s ful, 
potential at each stage in the development cycle before moving i to .the next. A hasty 
implementation could result in uneven acceptance and halfhearted participation. 
We are evolving to our own CASE tool kit in an innovative way CASE is not a 
prescription, it is an adaptation. People are beginning to use CASE because they 
have personal "ownership" of the idea. CASE is happening because the staff is 
creative enough to want it to. The staff, on its own recognizance, is seeking out 
novel solutions to our systems development backlog. Once again, it seems we have 
an environment that is encouraging creativity to flow. 

Yet another fruitful source of innovation at Penn State is end user computing. 
Several years ago we began the "user initiative" which put policies, procedures, 
tools and security mechanisms in piace to encourage end user computing. Today, 
we are seeing the early payoff of that initiative. Users are coming up with their own 
creative computerized solutions to doing their jobs better. Their activities are 
naturally being enhanced by the computer industry and its unending stream of end 
user computing tools. Again, there is an institutional willingness to cultivate this 
rich creative end user environment. 

Look, Ask and Listen 

We are not alone when it comes to innovation. To find source:, of innovation, we 
must keep our eyes, ears and minds open. CAUSE, as one example, is a tremendous 
source of creative ideas. Our sister institutions are anotner. To be creative we must 
look, ask and listen to the needs being expressed by others. It continually amazes 
me how simple it is to satisfy some of the most essentia! needs, if they are 
understood. It also amazes me how poorly most innovative opportunities J are 
communicated. Before we can create, we must convince others that it is important 
We must look, ask and listen to develop advocates for innovative ideas. By listening 
well we learn how to shape an idea and make it "right" for the situation at nana. 
The CASE solution at Penn State is "right" because diverse needs and opinions have 
embraced its benefits. 

As technologists, we must be better than anyone at finding the most creative 
opportunities. Challenge yourself, sometime, to enumerate creative things that you 
could do for your institution. I do this routinely. As a personal challenge and test of 
my understanding of Penn State, I routinely prepare a list of the five most 
important" things to b< done. The list changes with time. Some things lose heir 
importance. Others a;sume a greater prominence. To prepare the list Progeny, ! 
must inquire into the needs of other offices. I mustspend time with individuals and 
managers of those other offices to look, ask and listen to their greatest needs I 
must encourage them to brainstorm with me a little. Surprisingly, I find that the 
* *e most important things are not always intuitively obvious They spring forth 

irough creative exchange of ideas. They are typically crocs-d.scipl.ne changes that 

?sultfrom a global view. 

\2 
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Five Most ImportantThings 

• Enrollment Management 

• Personalized Correspondence 

• AIS Decision Aid (AIDA) 

• Electronic Application 

• Prospect Management 



Just A Little Beyond Our Grasp ! 



FIGURE 4 Five Most ImportantThings, 
Fall 1986 

Figure 4 is the list of what I thought were the five most important changes to be 
made in Fall 1 986, one year ago. I am showing them to prove a point. Once I 
understood that these were important, it was necessary for me to convince others as 
well. I do not arbitrarily impose my priorities onto our development schedule ... I 
try to influence others to change the schedule. The five most important things then 
become my agenda for lobbying. An innovative idea, no matter how good, should 
not be implemented if it is not accepted by others. The point that I wish to make is 
that the five most important changes from a year ago, have been endorsed, and are 
not in various stages of implementation. The five most important of this year are 
still under discussion. 

Simple and Small 

Peter Drucker observes that the most creative ideas are often the most simple. Penn 
State has a development strategy built around this principal. It is known as 
incrementalism or "chunking." It is not a major change, intellectually, but it is a 
major change from the past. Incrementalism is an approach to big system 
development which intentionally divides them into smaller chunks. Instead of 
considering all of the things necessary to build a personnel system, for example, we 
choose to think about those things that will give us the greatest payoff in the next 
few months. Amazing as it may seem to some, major achievements are possible in a 
short period of time. 

Many benefits derive from the incrementalist strategy. First, it causes us to better 
consider what changes are worth . If you focus on short term objectives, it is easier 
to say what is most important. The incrementalist strategy asks what can we do for 
you now"; not, "what do you need forever?" My observation, is that with the 
traditional PROBLEM DEFINITION approach, we tended to focus on global objectives 
rater than short term accomplishments. We tended to seek ultimate solutions. 
Expectations were raised and gratification delayed. A dangerous mixture that 
could, and frequently did, result in conflict. We didn't talk about important things 
that could be done now nor assign value to chunks that could be realized soon. 
Instead, we focused on master plans which would likely change during the 
development life cycle. 
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You might say the incrementalist strategy is creative because it naturally leads to 
valuable technological change. The most valuable changes find their way to the top 
of the list easily. At Penn State, for example, we had to find a new way of managing 
student progression to their major fields of study. Many majors are limited by the 
limited faculty and facilities that are available to support the major. The 
technological solution to this problem came to be known as AMPS — Advancement 
to Majors Preference and Selection System. It is a creative solution that gathers the 
preferences of freshmen and sophomores and then ranks the students that want to 
enter a common major. The AMPS system has proven invaluable for managing a 
complex and sensitive problem. 

Aim High 

The last piece of advice that Drucker offers for managing innovation is to "aim at 
leadership." This is the key to innovation. Throughout the previous sections, I have 
explained how we search the sources of innovation; look, ask and listen; and divide 
our activities into small and simple chunks. But, this is not enough. In addition, we 
must aim at leadership. We must seek out small, simple solutions that are at the 
edge of our technology. There are many examples of this at Penn State. 

Somehow, we want the very best systems with the most advanced features that are 
available today. We seek out solutions that are just beyond our grasp and it causes 
us to strive for excellence. Currently, we are working hard to expandend-user 
computing within a security framework that controls data access by function and 
value. The twin values of easy access and tight security controls are diametrically 
opposed. ..but we try anyway. We press the limits of fourth generation languages to 
achieve systems that are easy to build and, at the same time, efficient. We employ 
fiber optic links for improved terminal response times. We have begun using baluns 
for transmitting coaxial cable signals across ordinary telephone lines. We are 
implementing an electronic approval system for handling on-line forms. We have 
implemented FOCUS to integrate microcomputers into our telecommunication 
network for file sharing and local data analysis. We are implementing a new 
Student Longitudinal Research Flat File (SLRFF) for longitudinal analyses of student 
data. We are implementing a voice response registration system which can 
communicate directly with students by phone. Each of these innovative activities 
were initially thought to be beyond our limits but each is now well along the way to 
reality. Nothing is impossible as long as we strive for it. At Penn State, we aim high! 



CONCLUSION 

In this paper, I have tried to make the case for implementing technology in a new 
way, in a way that emphasizes creativity. I believe the basic reason is that our 
institutions expect us to. There are five simple principles which capture the 
fundamentals of innovative management: 

1. ■ Create or Perish If we don't, someone else will. 

2. Five Most Important - Challenge yourself to enumerate them. The first 
step of innovative management is to be able to recognize innovative 
opportunities. 

3. Least Size with Greatest Value -- Bigness is not a measure of value. 
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4. Results Now — First things first. 

5. Beyond our Reach — Strive for leadership. 

The challenge embodied in these principles is tantalizing ... a challenge summed up 
in the act of seeking small accomplishments, small accomplishments which can be 
achieved in a short period of time and, yet, represent bold new strokes in our 
technological infrastructure. This, then, is creative, or what! 
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JOINT APPLICATION DESIGN: 
Can a User Committee Ds. jn a System in four Days? 



Diane Kent, 
University of British Columbia, 

David Smithers, 
Computech Consulting Canada Ltd., 

Vancouver, B.C., Canada 



JAD (Joint Application Design) is a two to four day structured workshop in which 
users (including faculty and management) and the project analyst produce a fully 
documented application solution with enough detail to allow technical design and 
programming to begin almost immediately. Sound impossible? 

At the University of British Columbia we used a JAD for the first phase of our 
student record system development. The project in itself was an ambitious one - 
moving from a batch system with arena registration to a distributed system with 
touch-tone telephone early registration. Thus, using a technique which put a dozen 
users together in a room for four days to define and document requirements and to 
compbUs the functional design seemed like suicide to some. 

Using our experience, we will describe how the JAD process works, what results you 
can expect, how to adapt JAD to an educational environment, and how to ensure 
that the JAD produces a successful functional design. 
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INTRODUCTION 

Joint Application Design (JAD), originally pioneered by IBM about seven years ago, is rapidly 
spreading m use by North American organizations, both public and private. In addition to IBM, 
who have used JAD's on hundreds of their own projects, other well-known users of the technique in 
the United States include Texas Instruments and the Continental Bank. In fact, executives from 
these corporations recently shared their experiences with JAD in a James Martin/Deitak video 
series. In Canada, the technique was recently used by IBM to plan for and design all of the support 
systems for the 1988 Winter Olympics in Calgary. 

At the University of British Columbia we initially used JAD during the first project of many to 
re-design our student information system. The project itself is an ambitious one - moving from a 
fifteen-year old batch system with punched cards and arena registration to a distributed system 
using touch-tone telephone early registration. Thus, using a process which put a do~.en users 
together in a room for four days to define and document requirements and to complete the 
functional design seemed like suicide to some. 

We survived the experience, as you will see, and hope to convince you that if you control the scope, 
manage user expectations, give the information professionals the right tools, choose the right 
participants and adapt the technique to a higher education environment, a user committee can 
indeed design a quality system in four days, using Joint Application Design. 

WHAT IS JAD ? 

JAD is a technique that allows you to lever one of your scarcest resources - experienced people. It 
is a structured and intensive workshop involving primarily key Ub.rs and management, both faculty 
and staff, who are knowledgeable in the area of the business to be automated, and one senior 
analyst or project leader. The workshop is sponsored oy a committed executive, who understands 
the JAD process. It is conducted by a leader with special skills, who facilitates and manages the 
group dynamics of the session. In addition, although they do not directly participate in the 
workshop, key supporting players such as scribes, automated design tool specialists and a logistics 
co-ordmator are also invloved. (The individual roles of the major participants will be discussed 
below.) JAD is intended to analyze user requirements and complete the functional design of a 
system, replacing the traditional steps of requirements definition and systems design. 

In our JAD, we held one four-day workshop which covered the requirements and design of: 

- registration (including the dialogue for the voice-response system), 

- course scheduling and room bookings, and 

- supporting portions of the course catalogue and the facilities management systems 

In retrospect, this scope was far too broad. We should have held three workshops, with varying 
participants, for each of the sub-systems. Also, we should have considered holding separate 
requirements and design workshops to handle such a broad scope. It is a tribute to both the session 
leader and the participants in our JAD that the requirements and the design actually did get done in 
four days! 
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HOW THE JAD PROCESS WORKS 



The basic process can be viewed as a simple system, requiring certain inputs which must be 
prepared in advance of the workshop, the workshop (or S3 r stem) itself, and the outputs of the session 
which are reviewed and fine-tuned as part of the wrap-up, before becoming inputs to technical 
design and installation. We will focus first on the input side. 

Objectives and scope typically come from previous planning work. They are communicated to 
the team by the executive sponsor at the start of the session, together with any assumptions and 
constraints. 

A Familiarization Guide replaces the traditional requirements step of reviewing present systems 
and interviewing users. This guide is an informal list of forty questions which ask user participants 
about planning, receiving, tracking, assigning, processing, recording, sending and evaluating the 
work they do. In our JAD, these were prepared b)' holding several small group meetings with key 
faculty and Registrar's Office staff, with each group completing guides for each of the three systems 
under consideration. 

Pictures of the current process, an item not normally associated with requirements definition, is 
a valuable input to a JAD. These help participants focus on the reasons why the system is being 
developed or replaced, and give those who do not have day-to-day exposure to some aspects of the 
current process a better conceptual idea of the problems. During the preparation for our JAD, the 
University held its 1986/87 winter session registration, so various JAD participants were sent out 
trailing friends or relatives through the torturous mass registration process, which takes the 
average student about five hours to complete, waiting in long lines most of the time. 

Prototypes of the new systems may be prepared prior to the JAD. This is typically the case if you 
do a requirements workshop followed by a design workshop. In our JAD, although we did 
requirements and design in one workshop, the previous planning process provided sufficient detail of 
the requirements to allow the support team to build a prototype in parallel with other preparation 
tasks. This prototype proved invaluable during the session and was part of the reason why such a 
broad scope was successfully covered in one JAD. 

"What others do tf encourages participants not to re-invent the wheel. We were able to draw on 
the experience of the ever-increasing number of universities and colleges who have implemented 
telephone-based early registration. In particular, when the dialogue between the student and the 
system was designed, the team reviewed the dialogues of the University of Alberta and Brigham 
Young University, using these as a starting point for our system. 

What results or outputs can you expect from a JAD session? 

User or funct ; m} design specifications, including the benefits of developing the new system, 
are the main output. These ought to include: process models, data models and a data element 
dictionary; report, screen and form la}'OUts; and a prototype, either automated (preferred) or on 
paper. Our JAD, for example, produced over 200 data elements, 45 screen layouts and 17 reports. 

Issues are another important output from a JAD session. If you have the right participants, a 
large number of issues will be resolved in the session itself. However, the remaining issues will 
have to be assigned to someone for resolution by a specific date. In a higher education 
environment, a larger number of issues usually remain unresolved after the session, due to the 
decentralization of the decision-making process. We had 35 such issues identified in our JAD 
session. 
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planning. In addition, since we are reasonably sure that a large part of the system will be a 
package, we will have our first opportunity to use the JAD design technique for package selection 
and configuration. 

Other organizations have used JAD techniques for Information Resource Planning, Strategic 
Planning, identifying office automation requirements, and systems maintenance. 

While the JAD technique in itself can be used effectively in almost all stages of systems 
development, greater benefit, or leverage, if you like, can be gained via integration with other tools 
and techniques. We have already discussed the benefits of automated documentation and 
prototypes. If these can be linked directly to application generators, then the acceleration of the 
design stage can be duplicated in the programming stage. Further, once the system is in 
production, maintenance by regeneration through these tools will help protect the benefits gained in 
the earlier stages of development. In fact, if you can use JAD and an integrated set of tools right 
from the initial stages of strategic planning through to maintenance, then you will be in the 
forefront of technology and will be able to develop quality systems in a shorter elapsed time. 

It is only through this integration and acceleration of all phases of systems development that you 
can maintain the design quality and the user committment and enthusiasm built by the JAD design 
sessions. This has been a particular problem at UBC. We have a 4GL and other good development 
tools, but they are not linked to the automated design tools we used in the JAD, nor do we have an 
application generator for program development. Hence, we reverted to "classical" techniques for 
technical design, programming, and testing, which left a long elapsed time between the JAD and 
implementation. Fortunately, the academic policies and procedures which must be changed to 
accomodate an early registration system also took a long time to develop and approve, so the longer 
development time has not been entirely focused on the information systems group. 

SELLING THE JAD TECHNIQUE 

Selling the JAD technique usually requires a "champion" from any one of the participant groups 
(typically Information Systems) to lobby with management and executives for the use of the 
technique. The benefits of JAD, particularly the reduced elapsed time for design and the improved 
quality of resulting systems, are effective in selling this approach to senior management. Our 
champion was a newly-hired project leader who came to us via the local telephone company where 
the technique is used extensively. 

Once the executives and sponsoring management are "sold", JAD participants are identified and 
their availability for the session is arranged. The normal approach is to go through the 
organizational heirarchy, making arrangements with the department heads, deans or 
vice-president. While this works well with staff participants, the approach fails when used to 
arrange for faculty members* participation. We found that it is much better to approach the faculty 
members directly and let them decide the conditions of their participation and inform (or not inform) 
their department heads and deans. 

One of the biggest obstacles standing in the way of selling JAD is people-resistance. This 
resistance will come from all groups, but will be strongest in the Information Systems group. 
Visible executive and senior management support, together with participant training, will normally 
help overcome this resistance; however, this does not seem to work well with faculty members. 
Therefore, it is important that the executive sponsor be a senior academic administrator with 
considerable credibility both as an academic and as an administrator. We were fortunate that our 
sponsor, the Associate Vice-President for Academic Services, had been Dean of the Faculty of 
Science and has 35 years of experience at the University. When he talked, participants listened! 
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Lest you believe that a strong executive sponsor is all you need, a few words of caution about selling 
JAD are in order. Expectations about what will result from the JAD must be carefully ana 
constantly managed. For example, if implementation of the system is dependent on funding which 
will not be confirmed until after the JAD (as might often be the case in public higher education 
institutions), then participants should be clearly informed of this by the executive sponsor at the 
start of the JAD. Participants should be warned not to feel that their effort will be a failure if 
funding is not approved, since their continued committment and enthusiasm is often enough to 
obtain funding even if it is not immediately available. 

A second expectation which must be managed is the scope of the system to be delivered in the first 
phase. JAD participants are encouraged to be creative and even wishful in their thinking; hov:ever, 
they must realize that some of their good ideas will not be implemented until later phases, due U. 
budget, schedule or even technical constraints. If this expectation is not well managed, it can result 
in ill-will between participants and the project manager who is usually under budget and schedule 
pressures. All concerned must understand the project management triangle. 

You now know what a JAD is, what it can do for you, and how you can sell the idea in your 
institution. Next, you need to know how to get it organized. 

ADAPTING JAD TO AN EDUCATIONAL ENVIRONMENT 

In a universit}' you can plan the most logical, best orgainized system, with a great cost-benefit, 
implement it using the latest technology and methodology and still find that the system is a failure. 
JAD, we believe, can help you avoid this fate, if you learn to adapt it to the educational 
environment. There are three areas in which this adaptation is important. 

Getting the JAD Organized 

A typical 3- or four-day JAD session will take at least six weeks of preparation time. In a 
university, this could take even longer. How quickly can you select the project to use JAD on? 
How many committees have to approve this? Once you have the project approved, how quickly can 
you line up a meeting with the vice-president who is going to be the executive sponsor? ("Oh, I'm 
sorry, I'm going to be away for the next two weeks doing research at the end of the Nile" is an 
answer you are likely to get.) Then, having identified the project and the sponsor, how quickly can 
you get a room with the right audio-visual and computer communications facilities? ("What do you 
mean all these rooms are booked for the whole term an J I can only use them during Christmas 
vacation? It takes how many months to install a computer line? 11 ) This is all before you have even 
begun the six-week process of completing the familiarization guide. The message here is: don't 
start unless you a. e well prepared and have the right tools in place. 

The JAD Team 

Next, there is the question of the participants. The JAD guidelines tell you that the team should be 
composed of the business experts who either have the authority, or have been delegated the 
authority, to make decisions regarding both the system and the business objectives right in the JAD 
session. To select such a team, you must understand the culture of your organization. Naturally, 
you will have a committee to help you select the JAD team. You will describe the JAD process at 
length and end by telling them that you only want six people. You will then roll your eyes in horror 
and disbelief when they suggest twenty, and reluctantly let yourself be persuaded to accept nine or 
ten. One key to success is keeping your JAD team small. 



5 




107 



In many univerisiies and colleges, who you exclude is even more important than who you include. 
Do certain faculties believe that they have veto power over anything you do in a certain system? Is 
one dean much more vocal than the others 9 Should every faculty be represented? If they ar«i not, 
what is the risk? If they a*e, can they reach ever reach consensus? These are questions which you 
must be prepared to ask and to answer. 

Even more important in higher education is the participation of faculty members themselves in the 
JAD. You will certainly get asked by one dean if faculty have time for such frivolity. The answer, 
of course, is yes, but how do you reconcile this with a faculty member's teaching responsiblities and 
still get the full-time committment you need? At UBC, we developed a buddy system , which paired 
faculty members, so that one could attend the JAD while the other was teaching. 

Being aware of these potential problems and being creative in solving them will help you ensure 
that the systerr plains political acceptance as well as technical acceptance. 

The other member of the JAD team who must be selected carefully is the JAD session leader. You 
will need a person vvho is a good communicator and negotiator, but most importantly a good 
listene \ H* 1 or she must also be able to control a group, encourage creativity and, where necessary, 
use the power of persuasion effectively. Some experience as an educator will also be valuable. In 
aodition, this person requires technical skills in the areas of data modelling, data flow techniques 
and system design. 

Particularly important in a distributed system, such as a registration system, is a leader who is 
seen as neutral. A great deal of compromise is needed to design a successful system in such a short 
time, and thus the leader cannot appear to favour a particular user department or the information 
systems group. 

So where do you find such a renaissance man (or woman)? 

Many of the organizations who use JAD extensively have full-time staff who are well trained as 
JAD leaders. Most colleges and universities will not have such a person; and, if they did, somebody 
with such a high profile in the orgainzation would be in such demand that he would be out of th 3 job 
in three months. What UBC and others have done is U> find outside experts or consultants and use 
them to run the first few JAD's, while training one of the local staff members in the process. As an 
additional benefit you may find that consultants can offer advice on. structuring the JAD session, 
system design standards and concepts and approaches which have worked well in similar systems. 
As the technique is used more widely, you may find that you can trade session leaders with other 
institutions, especially to establish the leader's neutrality. 

Having finally organized the JAD and assembled the team, you will have to turn your attention to 
the JAD session itself. 

The Jad Session 

One of the most difficult tasks in the session is controlling the scope. Three days go by so quickly 
that if your leader is not able to keep the team within the scope you will find that the job is only half 
finished. Many of the participants will be so excited about being asked, for the first time, to design 
their own system that they will attempt to explore and resolve every possible problem. Also, the 
leader must not allow exceptions and rare problems to shift the focus from the main issues. 
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One of the ways to keep within scope, and at the same time keep the energy level of the session 

the - t y Variety ,l C ° nCentrate 0n one ™* <* th * sysSm for several h urs 
arealnd fi£ ? P ai ' tia ' COnclu * on ' then ^tch to a new area, returning later te finish the X 
of minutes However, if this approach is to work well, you will need a good set 



Taking minutes for a J AD session is an art, not a task assigned as punishment. You will refer to 
these minutes repeatedly during the session and find that they are a source of information and 

issssiL vtiiTe phases °r £ e n ect - j he rigour ™ th which *-* ^^cl 

recorded will be vital to the success of the design effort. In fact, in a JAD you will need at least two 

^^ZATJ^TK TT' P ° lideS ' dedSi0nS ' and a^dtteSnS 
scribe who handles the data model, data flows, prototypes etc. Of course the more vou Nn 

automate the tasks of both of these scribes, the more successful your JAD whM be 

Finally, the layout of the JAD room should be carefully considered to minimize distractions and 

AUdi °- ViSUal C ° mpUting ^P-ent e sh7lTu^ 
advantage, but should not be so obtrusive or extensive that it intimidates the particinants or 

tTmm f ' f im P° rtantl y> y° u wi » want to allow some observers (es'pe a 1 af the 
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process You must insist on a united number of observers and a strict rule of silence while 
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The JAD session is now organized and ready to begin. What can you do to ensure that tnis 
committee designs a horse rather than a camel? 

ENSURING A SUCCESSFUL FUNCTIONAL DESIGN 

sZ:^^zt s z^ at there are four areas on which you shouid co ™ to — a 

- the use of prototypes 

- focusing on what, not how 

- the systems environment 

- life after JAD 

We developed prototype screens before the JAD session and used these as a starting point to focus 

^of P t SC o USS , 10n - ? 1S aP u Pr ° aCh haS b ° th Strengths and weaknesses. As informTon system 
professionals we know that users generally do not know what they want until they have seen a 
version of it and worked with it. Prototypes can clearly fill this need. However w l a s 
beware of the infamous analysts' disease: "The problems I like are the ones which fi the olut onsl 
iSrfvprte fi WOr l S ' pr0t0ty P es devel °P ed before the final requirements are known can 

ee ratht h °" a °* ** ana]ySt and the tools > causing users to accept what tSey 

E£ ♦ ^ aSS f S u th u e ^quirements critically. You must, therefore, convince the analyst to 
design prototypes which have known flaws, so that the users will criticise the prototype, suggest 
improvements and begin to own the system. P ' suggest 

adekr 8 ?!!^!^^.^ 0 W Tu a , nalySt n0t to SUgg6St corr ^ions to the prototype too 
StfJ TZSZl . conce P , the anal y st must lea ™ * that the users have to take the time to 
design the system themselves. Many analysts are like Saint Bernards, rushing to the rescue of the 
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users and smothering them with solutions before ascertaining whether or not they really need help. 

One of the other difficult tasks for the session leader is to keep the users focused on what they do, 
rather than how they currently do it. Instead of saying, "I have to put the course cards in three 
different piles, one for the majors, one for the engineers and one for everybody else 1 ', the session 
leader has to teach the user to say, ,f I need to be able to reserve a certain number of places in a 
course for various groups of students". A prototype screen, introduced at an early stage and based 
on the current system's three piles, may result in the userc forgetting to ask the question, "Are 
there any courses which need to reserve places for more than three groups?" 

In developing prototypes and holding a design workshop, it is important that the session leader and 
the people doing the prototyping have a good knowledge of your existing systems environment. If 
you have screen design standards, insist on their use. If you do not have such standards, put them 
in place before the J AD begins. This will prevent time being wasted in the session discussing 
whether the screen name should be five characters or six random numbers, and whether it should 
be in the upper left-hand corner or the right-hand corner. The design will also proceed faster if the 
leader has a clear vision of what the whole system should look like and how it will interact with the 
users. 

After the design session, let the professionals who know the capabilities of your particular software 
polish the design and optimize it from a programming and performance perspective. Then, hold a 
design review, in which the systems professionals explain the changes they have proposed and ask 
the users for approval. It may be a humbling process for the systems people and lesson in reality 
for the users, but it is well worth the time and the effort. 

Now, having fin ; shed the enormous task of organizing and actually running a JAD, you turn your 
creation over to the systems development staff for programming. For a few weeks, the users who 
made up the JAD team feel relieved that it is all over and become immersed in their jobs, catching 
up on all the work which was left on their desks. However, they eventual^ emerge and begin to 
ask, "Is there life after JAD?" The answer is, yes! 

The team can still play a role during the systems development stage, and, in fact, is a resource 
which should not be lost. Despite the success of the JAD, design is never finished. In a large 
organization, like a university, you should have the JAD team conduct a prototype tour , so that all 
departments have an opportunity to provide input to the system. This tour, if properly managed, 
will result in a broad base of users committed to the system, rather than just the small group 
involved in the JAD. At the same time, the team should be using the prototype and the JAD 
minutes to develop user documentation, test cases and a training plan. After all, it is their system, 
so why would they want to let programmers write documentation for them? 

As programming progresses, new requirements are identified, programmers suggest better ways of 
doing things and users themselves may have new ideas. Re-convening the team periodically to 
review changes in the design is an excellent way to continually improve the quality of your system. 
At the same time, the team members can be assigned to follow up issues raised at the session which 
could not be resolved at that time. At UBC, we established an Advisory Committee, with 
representatives from each faculty, to deal with policy, procedures and implementation issues on an 
on-going basis, using the JAD team as key members of that committee. By being involved in these 
two activities, the team will continue the momentum and the committment built during the JAD, 
and, hopefully, spread the word to others in the organization. 
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CONCLUSIONS 



Can a user committee design a system in four days? Yes, hut in our experience you must pay 
carer U , attention to f.ve areas. First, keep the scope of each session as narrow as is practka , even 
if this means holdmg several two-day sessions rather than one four-day session. Second learn ^ 
manage user expectations, before, during and after the JAD. Third, give the information systems 
professumals the tools they need to make a JAD effective. Technology is now available to handle 

SETT* ^J"**** data dia S ramin S Proto^ing®! of which wiH gn^fican ly 
.educe systems deve opment t.me. If you do not have these tools or cannot get them, then you may 
not want to use the JAD techn.que. Fourth, choose the JAD team and leader carefully. The wrong 
users, even with a good leader, will not develop a quality system. Finally, don't be afraid to take 
the techn.que and adapt it to an educational environment. 
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Summary of Paper Presentation: 

Higher Education is being challenged by budget crises involving 
substantial reductions while at the same time technological services 
are being asked to increase support in all areas: increased access, 
improved response, more capacity, expanded consulting, a wider 
range of software, micro's and terminals, courses on techn/ogy and 
on-going upgrades in all areas. One can either wait for appropriation 
and/or allocations to increase resources or initiate a course of action 
which provides for growth and expansion by developing sources of 
revenue and by use of management practices which meet institutional 
objectives but eliminate those services where limited support and 
usage deny justified expenditure. 
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I. Background - 

A. Funding Status 

B. Student to Access Ratios 

C. Growth Data - Volumes/Applications 

D. Impact on Communications 

E. Microprocessor Influence 

F. Literacy Issues 



II. The Cost Center Approach - 

A. All Operative Areas are Cost Centers except one 
overhead entity - Vice President's Office/Business 
Operations. 

B. Cost Centers may be all or part revenue or 
appropriated funds. 

C. Centers grow by increased appropriation and/or revenue. 

D. Lack of growth of funds means lack of support. 
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III. The Consequence of the Cost Center Approach - 
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IV. Examples of Revenue Sources - 

Slides will be used to portrait organization and to illustrate 
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MAKING IT HAPPEN WITHOUT APPROPRIATION 

By: Robert E. Roberson 



Colleges and universities whether private or public, large or small and 
generally without much regard for geography face increasing costs, decreasing 
budgets and the possibility of substantial increases in tuition. An area signifi- 
cantly impacted by this situation is the area of providing technological services 
which for purposes of this presentation include computing, communications, 
software availability, application development, staff, hardware maintenance and 
training. Hopefully, any other areas of support can be adapted to the intent of this 
paper. 

The simplest way to illustrate the point of this paper is to make comparisons 
between what was and the way it is today and to communicate the methods used 
to achieve the change. 

In 1987, as in 1981, the University of South Carolina consists of a multi- 
campus environment with approximately 35,000 in head count and those cam- 
puses blanket the state. 
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Note: Areas where technical services are provided beyond the University are 
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The parenthesis under some of the two year campuses such as Union with 
(Laurens) indicates a satellite program in areas near the campus in question* 

In 1981 the only computing power in the University system was resident at 
the Columbia campus, with all other sites having terminals and in most cases 
remote job entry stations and printers available for both academic and adminis- 
trative computing support. Even on the Columbia campus with almost twenty 
three thousand students the only computing power existed in Computer Services 
with a four MIP AMDAHL V6-2, accessed by RJE stations and terminals from 
various labs and administrative offices on the USC campus. (There was one VAX 
11/780 in Engineering dedicated to a funded research project.) 

There were also approximately one hundred terminals and six RJE stations 
in state agencies which also accessed the AMDAHL V6-2. The usage by these 
agencies comprised almost 50% of the usage of the in place processor and 
generated approximately $900,000 a year in revenue which supplemented the 
appropriated budget which was $4.5 million for a total of $5.4 million as an 
expenditure budget. The long term indebtedness of the center was approximately 
four million dollars. 

The siafF consisted of 122 full time people organized as follows: 



System Vice President 
ComputingHechnoIogy 



Contracts 



Operations 



Systems 
Programming 



DBA 



Business 



Financial 
Systems 



Network 
Services 



Education 



Student 
Systems 



Academic 
Consulting 



Regional 
Campuses 



Graphics 



Data 
Communications 
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One of the critical issues requiring attention and improvement was the ratio 
ot students to access devices, whether terminals or micros. Even in 1983 that ratio 
was 415.8 to 1. 

The turnaround on the main processor was indefensible and the frustration 
of users was apparent every day. 

r *u S ° ufeC ^ otoaistodedonthebasis oi"aformulalumpsumbudgetprocess. 
In the last seven years the University has not been fully funded and in 1987 the 
funding level is at 86% of the formula. 

In fact, for FY 87-88 the appropriated technology budget under the System 
Vice President for Computing Technology was reduced by $482,000 from its 86- 
87 base, as were all other units of the University. 

Against this background the demands for increased service, more capacity 
new software packages, higher speed communications, never ending requests for 
more terminals, micros and research computing reached new heights. 

None of these actions were simultaneous, but over time the combination of 
such actions resulted in a dramatic change in our ability to respond to the needs 
of our user constituency. What did prevail was a conscious and deliberate 
management approach on which actions were based and on which decisions were 
madp. 



Very concisely the approach included these beliefs: 

1 . The demand for technology will always exceed the budgeted 
resources. 

2. Public service is a legitimate role of an educational 
institution and such service can be provided economically 
and to the advantage of the supplier. 

3. The technical component of the institution must be managed 
like a business, including incentives to stimulate growth 
and necessary reductions where "unprofitable" enterprises 
are clear. 

4. As with all businesses there are needs for "seed" money and 
the opportunity to invest must be recognized. 

5. The operating units within the institution's technological 
area must manage with flexibility and be permitted to use 
entrepreneural techniques where appropriate. 

6. Each unit of technology is viewed as a "cost" center charged 
with fulfilling its mission, growing against need and 
supplementing its cost center appropriation with revenue. 

The above guidelines for operation emerged in 1982 and have grown and 
evolved in practice with today's environments. Before addressing specific actions 
let me compare where we are today to the 1981 status previously noted. 
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Organizationally we now look like this: 



Systems 
Vice President 



Business Affairs 
& Communications 
Planning/Finance 



Systems 
Programming 
&OBA 



Office 
Automation 



1 



Micro- 
processor 
Procurement 



Office 
Staff 



Academics 



Consulting 



Administrative 



1 



Education 
& Training 



Financial 





Operations 



X 



Comm. 
Operations 



Network 
Services 



TSG 



Microfiche 



Scanning 



Production 
Control 




National 
Contracts 



State 
Agencies & 
Local Gov* 



The staff is now 190 people. 

The appropriated budget is 6.5 million which includes the absorption of 
communications and its associated $L3 million. Therefore, over the last six years 
the appropriation has actually increased from 4.5 million to 5.2 million or 15.3%. 
To the point of this presentation, our expenditure budget runs from fifteen million 



a year and higher and our capital indebtedness has gone from four million to 
almost nine million with an annual cost of over $3.5 million. 

Some of the key actions that provide us this environment have been: 

1. In 1982 all elements of the division were costed to establish 
billing rates. The costs were inclusive of all expenses, eg: 
capital, maintenance, staff, etc. 

2. All fixed contracts for external usage were eliminated in 
favor of billing on the basis of usage. 

3. Cost center budgets for operating units were established 
over the entire operation with over 50% of the 
expenditure budget as revenue based. 

4. Units unable to meet budget figures were reduced in 
expense (size) and frequently merged into other units. 

5. Marketing of technical services was embraced with vigor to 
include state and local government in South Carolina and 
other state and federal contracts. Currently, services are in 
place for federal systems, four other states and over seventy 
five agencies internal to South Carolina. 

6. A policy was established that for other than a university 
system microprocessor programming was not supported. It 
could be provided as part of service contracts for local 
applications. 

7. Long distance billings are handled by the communications 
component at rates less than commercially available, but 
beyond cost of providing such services. 

8. A microprocessor contract was implemented for resale to 
educational entities in the State. Over ihe last four yv.ars over 
$12 million in sales have occurred. 

9. Technical training/education is offered to any state agency at 
a fee per course. 

10. The typewriter repair service was absorbed and made a part 
of an existing maintenance group which bills at a lesser rate 
than the available maintenance contracts. 

11. A student fee was implemented to generate $1.5 million a 
year for obtainment of instructional equipment. 

12. Long term financing of equipment, predicated on a growing 
revenue base, allowed substantial increases in technological 
equipment without budget increase. 

13. Over fifty-five private lines access our resources with end 
users being responsible for costs. A bid was issued which 
resulted in an overage savings of 38% per line and a benefit 
of 15% to the data center. 

14. We are now in the process of preparing to bid cable television 
in the dorms. When completed with student rates offered at 
less cost than local cable companies it will more than pay for 
itself and provide 360 megahertz of data communications for 
broad band purposes to the University. 



15. Until 1984 most terminals, controllers and printers were 
purchased by departments. As with other types of 
equipment such as 5520 shared logic systems and remote 
controllers, the computing technology area established 
ownership of the controllers and processor units with 
terminals, micros and work stations the responsibility of 
end users. In place items were funded centrally; all new 
devices since 1984 result in end users "buying" a share of 
the control devices and a share of the maintenance. 

16. Maintenance on micros, terminals, controllers, typewriters 
and much of the communications equipment other than the 
PBX itself, is done by local technical staff. 



The consequences of the above issues have been substantial. 
Revenue has grown from $75,000 a month to in excess of 
$450,000 a month. 

External usage has dropped to 26% of usage but has risen to 

at least 50% of the expense budget. 

One-third of the programming staff is directly supported, 

including fringe benefits by contract programming and 

software maintenance contracts. 

The ratio of students to access devices is now 18.6 to 1 

(students to terminals and micros). 

In addition to two 3081 processors, a Vector processor and 
a VAX 1 1/780 centrally located, the University posesses six 
other VAX 1 1/780's in Engineering and Science and Math, 
an IBM 4381 in Business Administration, plus a number of 
smaller miniprocessors (at least twenty five). 
Within an eighteen month period, July 1986 - January 1988, 
two writing labs of twenty-four micros each and a ten station 
graphic lab will have been installed in Journalism. A fifty 
workstation lab is being put in place in Humanities and 
Social Sciences for teaching English and a graphic lab of 
twenty work stations for geographic needs in the Social 
Sciences. 

To encourage faculty to develop technological enhancement 
for infusion in disciplines is a need we must all address. An 
example of how the management theory herein proposed 
assisted is as follows: 



This past summer three levels of interaction were offered to faculty, ie: 
elementary, advanced and sophisticated course development. Subsequently, 
grants were awarded to limited numbers and over 75 faculty participated. The 
courses were fee based. Since that venture four faculty have obtained private 
funding to develop course materials making use of technology. Our staff support 
these activities in various ways and revenue is derived from direct payment, 
royalties or a combination thereof. 
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The above are only a few examples of substantial gains accomplished 
particularly in the last forty-eight months, which incidentally does not include a 
ten node 8700 line locally managed AT&T PBX environment. The latter and all 
other upgrades have been accomplished in a period when the appropriated budget 
is at a level in fiscal year 1987-1988 that is lower than it was in 1984-1985. 

There are management and procedural issues which become critical to the 
success of this approach. 

Constant and detailed interaction must occur between the cost center 
directors. This is pertinent for particularly two reasons. It is not reasonable or 
beneficial to have the operative areas behave as fiefdoms. It must be viewed as an 
organization of components, properly managed and "self sufficient" but all 
components must succeed if we as a whole are to succeed. Part of the interaction 
involves analysis of status by cost center which involves the sharing of data such 
as the following reports: 

1. Long Distance Status - Year to Date. (July through October, 1987) 



EXPENDITURES MONTHLY CUM. TOTAL 

TSI (TOLL) $81,324.38 $202,430.60 

TSI (MEGALINKS) $3,175.20 $6,16000 

OTHER: $ $ 

$ $ 

TOTAL EXPENDITURES $84,499.58 $208,590.60 
REVENUE: 

ADMINISTRATIVE BILLING $94,709.08 $315 57508 

STUDENT BILLING $8 1 ,657. 13 $ 1 64,82' 1 5 

CREDITS $ $ 

DEBITS $ $ 

TOTAL REVENUE $ 1 76,366.2 1 $480,447.23 

PROFIT/LOSS $91,866.63 $271,856.63 

TECHNICAL SERVICES (5%) $4,593.33 $13,592 00 

ADMINISTRATIVE SERVICES (5%) $4,593.33 $13 59200 

COMMUNICATIONS (90%) $82,679.97 $244,672 63 
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2. Cost Center Status Year to Date. (Revenue) 
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COST DESCRIPTION 
CENTER 



86-87 
REVENUE 



CURRENT 
REVENUE 



COO I 
CIOI 
CI 02 
CI08 
CIIO 
CI 13 



C002 
C003 
C004 
C007 
CI06 



CI05 
CI 1 1 

C330 



CI 14 



CI 12 
CI 15 
CI 16 
CI 17 
CI 18 



CI07 
C300 
C3I0 
C320 
C325 



C005 
C006 
CI09 



VICE-PRESIDENT 
ADMINISTRATION 
ADMINISTRATION 
ACADEMIC 
ADMINISTRATION 
AUDIOVISUAL 
TOTAL 

OPERATIONS 
OPERATIONS 
MICROFICHE 
SCANNING 
TECH. SUPPORT 
TOTAL 



$213,684 
$497 
$2,964 
$6,253 
$13,228 
$453 
$237,079 

$38,205 
$5,666 
$94,457 
$5,713 
$135,536 
$279,577 



ACADEMI C SERVI CES $48, 1 27 

ACADEMIC-MICRO $4,835 

ACADEMIC SERVICES $530,71 2 

TOTAL $583,674 



BUSINESS 

TOTAL 

ADMIN.-MICRO 
FINANCIAL SERVICES 
GENERAL ADMIN. 
STUDENT INFO. 
ADMIN. SERVICES 
TOTAL 

DIGITAL MAPPING 
NETWORK SFRVI CES 
NETWORK SERVICES 
NETWORK SERVICES 
NETWORK SERVICES 
TOTAL $ 

SYSTEMS & DBA 
SYSTEMS & DBA 
OFFICE AUTOMATION 
TOTAL 



MISC. REVENUE 
ADJUSTMENTS 
TOTAL 
OVERALL TOTALS 



$15,126 
$15,126 

$88,387 
$0 

$77,148 
$7,959 
$0 

$173,494 

$1 14,137 
$90,294 
$212,725 
$532,857 
$447,050 
1,397,063 

$39,589 
$675 
$41,966 
$82,230 



$2,390 
$84 
$193 
$775 
$1,577 
$0 
$5,019 

$2,673 
$1,218 
$3,1 13 
$1,732 
$9,601 
$18,337 

$3,416 
$1,039 
$35,793 
$40,248 

$935 
$935 

$4, 1 15 
$0 
$0 
$203 
$25 
$4,373 

$26,061 
$3,81 I 
$30,284 
$46,21 1 
$21,675 
$ 1 28,042 

$1,415 
$60 
$2,676 
$4,151 



PROJECTED 
REVENUE 
Y-T-D 

$35,614 
$83 
$494 
$ 1 ,042 
$2,205 
$76 
$39,513 

$6,368 
$944 
$15,743 
$952 
$22,589 
$46,956 

$8,021 
$806 
$88,452 
$97,279 

$2,521 
$2,521 

$14,731 
$0 

$12,858 
$1,327 
$0 

$28,916 

$19,022 
$15,049 
$35,454 
$88,810 
$74,508 
$232,843 

$6,598 
$113 
$6,994 
$13,705 



ACTUAL % OF 
REVENUE QUOTA 
Y-T-D 



$4,552 
$164 
$539 

$ 1 ,544 

$3,190 
$0 

$9,989 

$5,343 
$1,856 
$9,168 
$2,460 
$40,963 
$59,790 

$6,812 
$ 1 ,039 
$75,825 
$83,676 



13% 
198% 
109% 
148% 
145% 
0 

25% 

84% 
197% 

58% 
258% 
181% 
128% 

85% 
129% 
87% 
86% 



$935 37% 
$935 37% 



$8,287 
$0 
$5,835 
$571 
$25 
$14,718 

$54,404 
$8,400 
$107,684 
$95,662 
$52,293 
$318,443 



56% 
0 

45% 
43% 

51% 

286% 
56% 

304% 

108% 
70% 

1 37% 



$1,858 28% 

$75 66% 

$8,453 121% 

$10,386 76% 



$2,768,243 $201,105 $461,373 $497,937 107% 
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Status of Long Term Financing. 



BEGIN 


END 


MONTHLY 


FY 1987 


BALANCEC 1/87) 


Jan-84 


Dec-90 


32,387 


388,650 


1,613,91 1 


Jan-84 


Dec-88 


2,698 


32,376 


64,752 


Aug-84 


Jul-89 


763 


9,156 


23,653 


Jul-85 


Jun-88 


4,396 


52,752 


79,128 


Aug-85 


Jul-90 


38,466 


461,592 


1,488,552 


Sep-85 


Aug-89 


85,293 


1,023,516 


2,447,600 






Z,OJO 






Oct-85 


Oct-88 


25,840 


310,080 


568,480 


INUV od 










Nov-85 


0ct-90 


14,268 


171,216 


506,135 


Jan-86 


Dec-90 


2,774 


33,288 


1 18,303 


Feb-86 


Nov-88 


508 


6,096 


1 1 ,684 


Jun-86 


May-89 


9,938 


1 19,256 


264,419 


65200 


TOTAL 


257,027 


3,084,330 


8,399,667 


Jan-85 


Dec-89 


43,893 


526,716 


1,447,972 



Access Ratios - Students to Devices. 



SCHOOL TERMINAL MICROS 


TOTALS 


FTE86 


RATIO 


CRT'S 


FTE 83 


RATIO 












STUDENT 






STUDENT 












DEV 






DEV 


MEDICAL SCHOOL 


13 


10 


23 


278 


12.1 


2 


214 


107 


COLLEGE OF NURSING 


4 


8 


12 


356 


29.6 


0 


379 


0 


COLLEGE OF PHARMACY 


10 


32 


42 


215 


5.1 


0 


198 


0 


HEALTH 


22 


12 


34 


426 


12.5 


0 


417 


0 


HEALTH & PHYS ED 


2 


0 


2 


254 


127 


0 


278 


0 


PUBLIC HEALTH 


16 


8 


24 


141 


5.8 


0 


99 


0 


COMMUNICATIVE DISORDERS 


4 


4 


8 


31 


3.8 


0 


40 


0 


HUMANITIES & SOCIAL SCI. 


40 


253 


293 


6323 


21.6 


13 


6213 


477.9 


ART 


0 


3 


3 


294 


98 


0 


286 


r 


ENGLISH 


0 


31 


31 


1 178 


38 


0 


1 185 


6 


FOREIGN LANGUAGES 


1 


4 


5 


768 


153.6 


0 


768 


0 


MUSIC 


0 


1 


1 


330 


330 


0 


289 


0 


NAVY 


0 


2 


2 


37 


18.5 


0 


41 


0 


PHILOSOPHY 


0 


5 


5 


261 


52.2 


0 


264 


0 


RELIGIOUS STUDIES 


0 


0 


0 


82 


0 


0 


76 


0 


SBS LAB 


10 


82 


92 


0 


0 


5 


0 


0 
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SOUTHERN STUDIES 


0 


1 


1 


0 


0 


0 


0 


0 


THEATRE & SPEECH 


0 


0 


0 


233 


0 


0 


213 


0 


AEROSPACE STUDIES 


0 


0 


0 


18 


0 


0 


25 


0 


ARMY ROTC 


0 


0 


0 


18 


0 


0 


18 


0 


ANTHROPOLOGY 


2 


3 


5 


1 1 1 


22.2 


0 


126 


0 


GEOGRAPHY 


6 


1 d— 


1 R 




1 O 1 


A 
U 




A 


GINT 


3 


5 


8 


668 


83.5 


0 


737 


0 


HISTORY 


0 








/KJ.O 


A 
U 


ODZ 


U 


PSYCHOLOGY 


12 


86 


98 


895 


9.1 


8 


787 


98.4 


SOCIOLOGY 


6 


6 


12 


349 


29.1 


0 


318 


0 


HSSI 


0 


0 


0 


20 


0 


0 


8 


0 


SCIENCE & MATH 


17 




1 S 1 




Z 1 .0 


1 -7 
1 / 


34Zo 


201.6 


REMOTE 1 


9 


44 


53 


1649 


31.1 


8 


1643 


205.4 


BIOLOGY 








683 






669 


0 


CHEMESTRY 








515 






584 


0 


PHYSICS & ASTRONOMY 






451 






390 


0 


REMOTE 43 


8 


90 


98 


1604 


16.4 


9 


1785 


198.3 


GEOLOGY 








249 






345 


0 


COMPUTER SCIENCE 








283 






378 


0 


MATHEMATICS 








935 






947 


0 


STATISTICS 








137 






1 15 


0 


APPLIED PROF. SCIENCES 


23 


31 


54 


752 


13.9 


0 


1468 


0 


BUSINESS ADMINISTRATION 40 


88 


128 


2888 


22.6 


14 


2845 


203.1 


CRIMINAL JUSTICE 


6 


31 


37 


168 


4.5 


0 


176 


0 


EDUCATION 


5 


30 


35 


1 193 


3.4 


0 


1494 


0 


ENGINEERING 


200 


20 


220 


734 


3.3 


0 


779 


0 


COLLEGE OF JOURNALISM 


4 


25 


29 


287 


9.9 


0 


352 


0 


LIBRARY & INFO. SCIENCE 


3 


18 


21 


135 


6.4 


0 


81 


0 


COLLEGE OF SOCIAL WORK 


1 


9 


10 


232 


23.2 


0 


149 


0 


UNIVERSITY 101 


2 


3 


5 


220 


44 


0 


162 


0 


LAW SCHOOL 


8 


2 


10 


785 


78.5 


0 


770 


0 


TOTAL 


398 


706 


1 104 


18245 


16.5 


45 


19125 


415.8 



Individual cost center directors have the opportunity to prioritize new needs 
based on their own or some other cost center margin above revenue projections and 
include positive revenue positions in areas such as long distance billing. 

Furthermore, the dependency on revenue to meet expenditure commitments 
and for new ventures is reviewed from an operational relationship perspective. 
Which is to say very little occurs where less than two cost centers are not involved 
in the support of a project. Projects are analyzed in terms of available resources 
and user benefits and the margin of gain in the revenue stream. In most cases the 
revenue is shared by multiple cost centers based on a percentage established 
according to the level of support provided. 

The awareness of how our information technology operates has resulted in 
constant inquiry regarding our services. This not only applies to development and 
production projects but to the level of assisting in obtaining better rates in areas 
such as private lease lines for end users. In this particular case end user costs were 
reduced by as much as 40% and our revenue for that effort was 1 5% of the savings. 
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Although a sophisticated billing and accounting system is a prerequisite for 
this project the benefits are clear. 

1. The University has 50% more technical resources available 
than would otherwise exist. 

2. Cost center directors not only manage technology but as well 
manage their units destiny within the parameters of our 
goals and missions. 

3. The spirit of it is business and entrepreneuralism has 
established a motivation within groups and individals that 
translates into "we can grow as much as we want and are not 
constrained by a lack of funding." (In most cases this 
expands the opportunity to enhance the magnitude of 
knowledge in the latest technologies). 

4. There are opportunities for economical gains by individuals if 
projects are undertaken where substantial time and effort is 
required of staff members* personal time and is over and 
above his/her regular job tasks and expectations. (This is an 
identified and negotiated matter before any such efforts). 

It should be noted, however, that since this was initiated 
attrition has dropped from about 25% to 12% per annum. 

5. The availability of such revenue has expanded the benefits of 
off-site training, technical conferences and in-house get 
togethers, all of which contribute to the gains achieved and 
staff morale. 

We are frequently asked, "Why do you do this?" The response is simple. If you 
do not grow you cannot meet the needs of the institution and it is unlikely you can 
expand technologically without sufficient funds. With appropriation unequal to 
the demand we can either wait for additional funding or take the responsibility of 
supplementing the appropriation in sufficient amounts to accommodate the 
technical needs. For those of us who have enough funds to meet our needs, we are 
fortunate. For those of us who do not, this is an example of one course of action. 
It is demanding, sometimes precarious but is also fun and rewarding for you, your 
staff and your institution. 
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PROTOTYPES AND SIMULATIONS AS DECISION TOOLS: 
INCREASING THE SOFTWARE IMPLEMENTATION SUCCESS RATIO 



Elliott J. Haugen 
Brian P. Nedwek 

Saint Louis University 
St. Louis, Missouri 



ABSTRACT 

Implementation of purchased administrative software requires design 
and decision testing strategies focused differently than in traditional software 
development projects. Although vendor-developed software may closely match 
an institution's needs, there are still significant project challenges. Purchase 
decisions often do not/cannot include rigorous analysis of institutional policy 
and procedural implications. Successful system integration, within the context 
of policies and procedures, suggests the need for decision verification tools. 

This paper describes efforts to bridge the software-context gap through 
the use of prototyping and simulations. These design/decision testing 
approaches were used in a recent student information system implementation. 
A prototype was used to orient project teams to software capability, to test data 
base decisions, to bring meaning to the developing product, and to transfer the 
focus from a technical to user orientation. Simulations helped validate policy, 
procedural and software decisions and interactions from both the service 
provider and client group perspectives. 



Prepared for CAUSE87 
Tarpon Springs, Florida 
December, 1987 



ERIC 



38 



Prototypes and Simulations as Decision Tools: 
Increasing the Software Implementation Success Ratio 

INTRODUCTION: 

The evaluation and use of purchased administrative software within 
higher education institutions is an obvious and accelerating trend. Purchased 
systems have thrived as alternatives to traditional system developments due 
to increased functionality, data base capabilities, cost-effectiveness and 
access to more timely solutions. While vendor-developed software may closely 
match an institution's needs, there remain significant implementation 
management challenges. Especially problematic is a project's early, and 
appropriate, emphasis on software product evaluation and selection. Purchase 
decisions often do not and cannot include rigorous analysis of institutional 
policy and procedural implications. Successful implementation of a purchased 
software system depends, therefore, upon its integration within the context 
of institutional policies, procedures and organizational culture. This 
requirement suggests the need for design and implementation decision 
verification strategies which can be systematically applied to validate the 
impact upon existing and changed policies, procedures and organizational 
norms and values. 

One approach to bridging the software-context gap is through the use of 
software system prototyping and process simulations. These design/decision 
testing approaches were used by Saint Louis University in a recent student 
information system implementation. A prototype was used to promote team 
members' understanding of the software capabilities, to test design and data 
base decisions, to bring meaning to the developing system and to transfer the 
focus from a technical to user/policy /procedure orientation. A simulation, 
in the form of a complete mock registration process, helped test policies and 
procedures from both the system development team and user group perspectives. 

BACKGROUND: 

Saint Louis University is a private, liberal arts institution dedicated 
to the Jesuit tradition of education. The University, founded in 1818, is 
the oldest university west of the Mississippi, enrolls over 10,000 students 
and employs 4,000 full-time and part-time faculty and staff. The University 
consists of the Frost campus, Medical Center/University Hospitals and Parks 
College in Cahokia , Illinois . Academic offerings include undergraduate , 
graduate and professional programs, medical school, law school, Parks College 
(aerospace and avionics) and affiliated programs in Spain and France. 

In 1984 the University began a major effort to upgrade its administra- 
tive information systems. New software and hardware systems were purchased 
and successfully installed into production for financial accounting (July, 
1985) , alumni/development (July, 1985) , payroll/personnel (December, 1985) 
and student information management (October, 1987). These systems use 
Information Associates' Series Z (FRS, ADS, HRS, SIS) software running on 
three Digital Equipment Corp. (DEC) computers (VAX 8530, 11/785, 11/750) 
linked under a VAXCluster architecture. Over 200 workstations (terminals and 
microcomputers) are connected to these on-line, integrated data base systems. 
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IMPLEMENTATION CHALLENGES: 

Saint Louis University (SLU) began implementation of a University- wide 
student information management system (SIMS) in 1986. Papers describing 
software selection, previously installed systems (FRS, ADS, HRS) , project 
organization and computing implications have been presented at CUMREC85 and 
CAUSE85. This paper explains how specific design and testing techniques can 
be used to evaluate and refine implementation plans and decisions as to their 
impact upc and interaction with, institutional policies and procedures. 

Implementation of a student information system is an institution's most 
complex computing challenge. It includes multiple components (admissions, 
student records, billing/receivables, financial aid management, housing, 
institutional research) and involves more people. It extends data base access 
and functional responsibilities further into the user community and at an 
earlier stage than other information systems. The "go- live" process is also 
more complex due to multiple subsystems. SIMS went live September 24 for the 
schedule of classes; October 26 for on-line early registration (11 sites, 25 
workstations); October 27 for undergraduate admissions (6 other offices 
followed); November 2 for cashiering; December 5 for tuition calculation and 
billing; and December 14 for financial aid. SIMS also encompassed three 
campuses and several academic calendars (semester, trimester, year). 

The SIMS project was organized around a project director, four 
implementation teams for the functional components, and a core team 
responsible for shared data elements, reporting and institutional research 
requirements. User-led teams consisted of users and computing professionals. 

A succ *ssful selection/purchase process should result in implementation 
as closely as possible to the delivered base software. The import of picking 
a "best" package is lessened if excessive customization is a perceived need. 
Conversely, one must not ignore the fact that purchased software is not an 
"off-the-shelf" solution and implementation must be viewed as a system 
development process. Software design and programming tasks are eliminated, 
but system development must still provide an "institutionalized" solution 
which integrates the software and data base with policies, procedures and 
needs. SLU committed very early to a minimum-customization implementation. 
This increased the importance of team members thoroughly understanding the 
product's features and capabilities; it also reduced expectations that the 
software would be changed to fit individual nuances or old practices. 

As the project implementation began, two basic categories of tasks began 
to surface: software -related and data-related. Initial issues and questions 
were software focused due to the team members early exposure software 
selection and vendor software orientation. Although each team w tt s involved 
in documenting current practice and policy, the software bias threatened user 
participation by tending to concentrate on technical rather than functional 
requirements. The data-related tasks began as data conversion planning, but 
quickly developed into procedural, training, forms and reporting objectives. 
Figure 1 summarizes major project tasks cast against a project window 
representing time and effort. This task versus time grid becomes three 
dimensional when integrated with institutional requirements in the form or 
management, operational and information needs; existing and changed policies 
and procedures; and implementation constraints (schedule, personnel, budget). ' 
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MAJOR SIMS PROJECT IMPLEMENTATION TASKS 
RELATIONSHIP of 'EFFORT vs TIME LINE 



F 
F 
0 
R 
T 



SOFTWARE-RELATED TASKS Adjustments Made 

Interfaces Tested 
DBD Finalized 
Design Refined 
Procedures Defined/Changed "Go-live" 
Features/Capacities Validated Data Base Loaded 

^"f^" ^ues Addressed User Training Held 

DBD Values Defined ^ Workstations Installed 

Forms/Publications Designed 
Operational Details Defined 
Decisions/Procedures Finalized 
SLU Data Pre-Loaded/Validated 
Reporting Requirements Determined 
Test Data Collected 
Data Conversion Planned 
Data Flow/Use Defined DATA-RELATED TASKS 



Team Training 
Project Planning 



July 
1986 



Oct. 



Jan. 
1987 



April July 
PROJECT TIME LINE 



Oct. 



Jan. 
1988 



Figure 1 



Four major project management challenges were envisioned durine the 
planning stages or developed early in the implementation process: 

1. How to foster a thorough understanding of the software's functional 
features, internalized within the context of desired outcomes. 

2. How to transform the participant's orientation from a technical and 
software focus to a user/procedural emphasis; or how to move from the 
software-related tasks (which would diminish with time) to data-related 
tasks which would comprise the most substantial future workload. 

3. How to guide the five concentrated, parallel team development efforts 
toward convergence into a single, integrated, and efficient solution- 
and how to provide a means to identify and address policy and procedure 
assumptions, cultural conflicts and differences of views. 

4. How to test design decisions, software solutions and procedural changes 
thus increasing the project success ratio (reducing risk of failure) 

The first two challenges generally do not exist in a traditional system 
development, but significantly compound the complications inherent 2 the 
last two concerns. The University addressed all four project management 
issues by utilizing two specific system development strategies: prototyping 
and simulations. These tools are not new, but their systematic application 
within a purchased system implementation may have been. Nevertheless these 
tools provided valuable design and decision evaluation forces for alleviatW 
obstacles and accomplishing project goals. ^eviacing 
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PROTOTYPING: 

The use of prototyping as a system development tool has grown consider- 
ably in the last few years. While usually associated with traditional system 
development efforts, prototyping also has application within a purchased 
software implementation. Prototyping has been defined as the creation of a 
"working model of automated information processes which begins as a trivial 
representation, and evolves into a full-scale functional information system" 
(Little and Lowry, 1985). Other definitions emphasis benefits such as 
greater user involvement in the development process thus fostering ownership 
of the application project. Lately, discussions have focused on the numerous 
prototyping tools, such as 4GL's, CASE (Computer-Aided Software Engineering), 
code generators and screen builders. However, recent studies at the State 
University of New York at Buffalo suggest the usefulness of prototyping is 
diminished if the development process itself is not well understood or is 
overshadowed by the software tools themselves. It was noted that "Systems 
developers are so enthralled by today's graphic, narrative, and 
representational modeling aids that they are losing sight of their mission 
and forgetting that the map is not the territory." (DATAMATION, 1987) . 

Saint Louis University utilized prototyping as a development tool in 
its SIMS project to integrate the purchased software and associated training 
with system analysis requirements and to develop a final product focus. This 
formal 3-month team effort started shortly after training, not as a training 
extension, but as a tool to finalize and test decisions. A prototype was 
created combining the purchased software with a functional SLU data base and 
operationalized according to institutional policy and procedural decisions. 
It supported all activities of the specific functional areas (student 
records, billing, et:c), although not for all colleges, courses, terms, 
students, etc. Within pre-determined parameters, the prototype was developed 
to be a fully functioning SLU student information management system. 

A copy of the base (training) software was loaded with SLU data base 
values for a defined subset of SLU courses, colleges, students and financial 
conditions. The prototype effort paralleled actual semester activities and 
used SIMS processes to test term schedules, sessions and calendars; course 
schedules; multiple sectioning; department/subject redundancy; admissions; 
registration procedures; student schedule printing; tuition calculation; 
residence/board charges; financial aid awards and disbursement; registration 
cancellations, drop/adds and withdrawals; refunding; GPA initialization and 
calculation; grading and changing grades; transcripting; standard and ad hoc 
reporting; plus other system (FRS, HRS) interfaces. 

A common orientation early in a software implementation effort is that 
a system must work under all conditions and all cases, or it does not work at 
all. This misplaced perfectionism, or paralysis by analysis mode, is a major 
obstacle to development progress, i.e. all step 1 tasks and problems must be 
completely solved before step 2 issues are addressed. Prototyping overcame 
this problem and affirmed the 90-10 rule -- if the initial design worked for 
90% of the cases, then future time could be focused on the remaining 10%. 
There were three other important outcomes: decisions were forced, procedural 
assumptions disappeared, and teams were sensitized to the importance of 
interteam coordination and communication. Prototyping verified which designs 
and decisions worked, but most importantly, made known what wasn't known. 
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SIMULATIONS: 

The formative evaluation of systems and procedures using a robust 
simulation was another key factor in the SIMS implementation. A simulated 
registration using students and office personnel was held to test final 
design, decisions, processes, procedures and documents/forms. The results of 
these tests were used to further refine the systems for the "go-live" stage. 

Planning the simulation required the development of four distinct yet 
interrelated components. The first component involved goal specification, 
i.e., stating specifically what was to be accomplished through the 
simulation. The process by which test goals were articulated called for each 
team to submit a list of the SIMS data base elements and transactions to be 
tested. This step was followed by a series of team leader meetings where the 
test agenda was synthesized. Four goal sets resulted: 

1. Test the software in a variety of applications, e.g., cross-listed and 
co-requisite course requests, tuition calculation under various 
combinations of college rates, fees, etc.; posting of payments against 
tuition charges, fees and outstanding balances. 

2. Test basic processes and procedures, e.g., course conflict resolution; 
timing of registration episodes including completion of a registration 
form , registration confirmation , billing , receipting , financial 
arrangement processing; payments made by cash, check or third party 
sponsors; and authorization signatures. 

3. Evaluate basic documentation and forms, e.g., schedule of classes, 
registration form, instructional materials for advisors and students! 
Assess user understanding, satisfaction, ease of use and common errors! 

4. Test administrative support processes and procedures, e.g., the quality 
of staff instructions and training; type and frequency of data entry 
errors; staff response to questions from users; tuition charges 
reconciled to income accounts; and among others, hardware performance 
(computer response time, terminals, printers). 

The second planning component involved development of a linkage between 
these test goals and the mock registration. The primary linkage was through 
the creation of 100 student biographies. Each biography reflected a combina- 
tion of the following characteristics: 

Undergraduate, graduate or professional 
Academic unit wherein the student was enrolled 
Year in school e.g., freshman, first year law, etc. 
Key to selecting courses, including "required" 
Rates applicable to distinctive programs 
Total number of credit hours requested 
Full or part-time student status based on load 
Residence and meal plan variations 
Amount of open balance prior to registration 
Pay full amount due or use budget payment plan 
Amount and method, e.g., cash, check, third party 
Whether or not the student received financial aid 



1. 


Student Type 


2. 


College 


3. 


Classification 


4. 


Major 


5. 


Special Tuition 


6. 


Credit Hours 


7. 


Time Status 


8. 


Dormitory 


9. 


Open Balance 


10. 


Payment Plan 


11. 


Payment 


12. 


Financial Aid 
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A biographical sketch was given to each participant as a student role 
to play in the simulation. The proportion of biographies with similar char- 
acteristics, e.g., full-time Arts and Sciences students receiving financial, 
aid, approximated actual registrations in recent semesters (Kalsbeek, 1987). 

The third planning component involved "seeding" the simulation to test 
the software and staff behavior. Some student biographies included 
instructions to register for certain courses thus creating combinations that 
should have been unacceptable, e.g., an undergraduate student requesting a 
course from a professional program. Responses to system messages by 
registration staff and students were monitored. Course offerings were also 
seeded. Errors in the Schedule of Classes were used to assess how the 
software and personnel responded to various system messages that appeared at 
the workstation terminals. Courses were set with enrollment limits to test 
the usefulness of standard reports, e.g., closed section and demand data. 

While testing the software was a high priority, assessment of the 
actual flow of registrations was critical. Given the limited number (100) of 
registrations available, two sets of registrations were prepared in the event 
a "load leveling" intervention would be needed. This contingency plan would 
provide students with a filled-out registration form to be taken directly to 
a registration station to assure a relatively even flow of registrations; the 
simulated registration ran so successfully, this plan was not necessary. 

The fourth component involved site selection, registration artifact 
creation and participant recruitment. A balance was struck between the need 
to simulate the physical environment of past registrations, e.g., ballroom 
style registration and the need to manage the evaluation component of the 
simulation. As a result, a miniaturization of the ballroom format was 
achieved with the number of workstations at each function proportionate to 
the past number of registrations serviced, during a typical General 
Registration period. Personnel from the functional offices were trained and 
staffed the various stations. Registration artifacts included the use of 
"play" money, temporary student ID's and simulated checking accounts. 

Participant recruitment attempted to achieve two goals. Not only were 
articulate students from a variety of backgrounds sought to participate and 
provide feedback, but also an attempt was uiade to create "interest" in SIMS 
among student leadership. Because of the latter goal, the main source of 
recruits was a student leadership organization. It was anticipated that such 
students might become trained aids for the actual registration. For various 
reasons, the number of student leaders recruited was below test needs. 
Additional recruits were obtained from summer school attendees and student 
employees. In July, 30 student volunteers attended an orientation session 
and were given instructions as to their roles and "identities". Three hours 
later, 100 registrations had been processed. The volunteers were compensated 
with gift certificates and dinner after the evaluative debriefing session. 

Evaluation Plan 

Evaluation of the simulation was organized around four components. The 
first component called for the measurement of the amount of time needed to 
complete a registration. A model of anticipated processing times had been 
prepared, but required validation. Timers unobtrusively recorded the amount 
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of time required for a student to complete a particular episode, e.g., obtain 
a confirmed student schedule, obtain a printed bill and make a payment to a 
cashier. 

The second component of the evaluation plan called for the application 
of a focus group technique to obtain registrants' expressions of their 
experiences. Long used as a qualitative marketing research tool (Calder, 
1977), this technique was used as an exploratory approach to student 
perceptions of the registration. It was intended to generate a kind of 
prescientific knowledge of the registration episodes. This knowledge was 
compared with the quantitative data yielded from registration timing. 

Each focus group was composed of seven registration participants and a 
moderator who had been trained and provided with a discussion guide. Each 
group session lasted approximately one hour and fifteen minutes and was audio 
recorded. A transcription of each session was prepared for the project team 
leaders and moderators completed thumbnail sketchs csf their groups. 

The third component of the plan included development of various reports 
from user groups. For example, reports were prepared on tests run after the 
mock registration, e.g., comparing cash register check-out against opening 
totals, amount and number of financial aid disbursements, and the like. 

The final component of the plan included student responses to questions 
about each registration they had experienced. As each student completed a 
registration, they returned to the staging a^ea to obtain their next 
biography. At this time they were provided a feedback sheet to record their 
initial impressions of what had occurred during their registration episode. 

The Results 

Timing results for registration episodes were relatively straight- 
forward and described such characteristics as (1) average time spent at a 
registration station during the initial interaction (it was possible for some 
students to appear at a registration station more than once to complete a 
registration); (2) average duration of subsequent registration interactions; 
(3) average time of combined interactions; (4) average time spent in student 
accounts; and (5) average time spent at the cashier's station. Additional 
analyses wore planned, e.g., average time of episode by type of registrant, 
but minimal variation in the length of each episode stayed further analyses.' 

Transcriptions from each focus group session and student comments on 
feedback sheets provided two more sources of data. The transcripts provided 
a rich source of feedback information about participant perceptions of the 
processes and procedures. A typical student response was: 

"The only problem was that you don't have a copy of your original 
(registration form) to compare it with what you get out of the 
computer and I was just wondering if when you're registering, are 
you going to be able to tell when they're typing it in if it's 

the^ same class or not [T]he alternate section (of the 

registration form) was very helpful because there was one time 
where a class was cancelled and there were no other sections 
offered so they went to the alternate courses and it helped." 



The fourth source of data was derived from analyses of work samples or 
post-simulation testing by each team. For example, students who were 
scheduled ^ to receive financial aid were compared with the actual 
registrations. Some teams had planned to test the capacity of the system to 
generate standard reports, e.g., class Uses; but limited resources and time 
pressures made such evaluations little more than ritualistic. 

Translating Results Into Decisions 

The mock registration began as an attempt to validate the design 
assumptions underlying SIMS. The implicit process by which these validations 
were^ to occur was a form of classic rational deliberation. Under these 
conditions, team leaders were to measure system performance against the basic 
design. The evaluation was to assess fidelity to design. In a sense, the 
effort might well be described as a ceremony of celebrating the faithfulness 
of field operations to the design. This activity, or rite, is intended to 
maintain the existing organizational culture (Trice and Beyer, 1985). 

While changes in process, procedure and form that occurred after the 
simulation can be described, a more important lesson is the process by which 
these changes were decided. For example, the decision to have a single ply 
registration form to be retained by the student and similar form decisions, 
really did not occur in any formal way. Rather sense impressions gathered 
through the experiences of the simulation, coupled with the transcriptions of 
the focus group sessions were transformed into the everyday language of the 
team leaders. Thus, as the project moved toward the final stage, changes 
appeared as happenings more so than as the result of formal deliberations. 

The degree to which the mock registration "fit" the design could have 
been the consuming agenda in the days immediately after the simulation. Were 
the teams to have applied a traditional deductive model, precious time would 
have been lost, frustration increased, and morale depleted. What occurred 
was that decision refinements simply happened. 

Subsequent SIMS teaa leader meetings and formal and informal gatherings 
are perhaps better described by "how rules, rather than guiding this process 
emerge from it" (Garfinkel, 1967 in Brown, 1978 p. 369). That is, decisions 
began to happen and were followed by their rationale. In a sense, results 
were not "translated" into action; results were the actions! The heightened 
intensity of the SIMS project that resulted from the simulation appeared to 
transform the teams into what has been described as a "high performing 
system." In such systems, "...people actually agree, without going through 
the tortuous processes of negotiation and conflict management" (Vaill, 1981, 
p. 35). 

The mock registration process unshackled the immobility or malaise so 
frequently experienced following the intense design stage of project imple- 
mentation (Haugen, 1985). Teams lost their fear of failure and gained a 
vision of success. Interestingly enough, the design was so complete and the 
results so successful that project management decided to expand the planned 
number of registration sites and workstations. This success was realized 
because the simulated processes were viewed as a final test of decisions and 
developed solutions. Just as the prototype initiated a reality of an 
institutionalized system, the mock registration confirmed its completeness. 



9 

46 



132 



SUMMARY: 

The use of prototyping and simulations as decision verification tools 
has been shown to have both intended and unintended consequences for project 
manageiaent. The prototype strengthened project teams' understanding of soft- 
ware capabilities, allowed members to internalize the linkages between 
processes and software elements, and transferred the focus from a technical 
to user orientation. The simulations validated policies and procedures from 
both service provider and client group perspectives . The use of these 
decision^ tools had the unintended consequences of strengthening morale, 
heightening confidence levels, energizing user training, and providing the 
momentum to move the project into the final phases of implementation. 
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ABSTRACT 



Information is one of the basic resources available to the 
manager, just as valuable as human, material or financial 
resources. The ability to provide information depends on the 
files and data that is captured and stored. This paper will 
discuss the files needed to manage a large university and the 
tasks required to extract the data into information. To obtain 
this goal, there must be a strategic plan. 

Management Information Systems is no more important than strategic 
computing. The evolution of the MIS concept from an initial focus 
on data through expert systems, decision, support systems, 
artificial intelligence and the ingredients for strategic 
computing will be discussed. 
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INTRODUCTION 



Information is the most important asset we can have when it is necessary to 
make management decisions that involve the expenditure of large sums of monies 
for the labor and materials required to produce a product. In other words, 
what we know about the business cycle of our business can only help us in 
making good decisions. Maintaining our business data and producing informa- 
tion is what Management Information Systems is all about. We can't have this 
information unless we plan for it. Understanding what data we should capture 
into what files and how they are interrelated is important. Why? Because it 
is the capturing of this data over time, the history of our business trans- 
actions that allows us to obtain the information we need to forecast our 
future business. If we don't capture it, then we don't have the data that is 
necessary for providing us this wealth of information. 

Since our product is the education of students, we will concentrate on the 
needs for providing information at the operational and management level of a 
two or four year institution. 

DEVELOPING SYSTEMS 1970 THROUGH 1980 

The building of a total management information system at the University of 
Akron started in 1965. The tools were simple with cards and magnetic tape the 
only available media and the language was COBOL. By 1974, we were looking at 
on line systems and the strategy was based on completing the systems required 
for selling our product first. That is, we had a plan to complete the stud^ic 
records area, payroll/personnel second and financial last. We did not at that 
time have a complete plan. Today we have a formal plan built on the structure 
of the organization. The systems we implement are managed through a total 
Project Management System that relies on good standards and procedures. That 
is to say that our systems are developed using the standard life cycle and 
estimates are made for each task within a development phase. At the end of 
each week, time is accrued and reported on each system under development. 

The Job Accounting System is designed around the computer standards for system 
development and operational use. That is to say, our system naming standards 
that tie the system and all of its parts together are used with the Job 
Accounting System even to the point that the disk file names are tied to the 
Job Accounting charge number. At such time as the charge account number 
expires, the disk data set will be purged and backed up to tape. Yes, the 
files can be restored. 



WHAT FILES ARE NEEDED TO COMPLETE A MIS FOR COLLEGES AND UNIVERSITIES 
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If we want to build a total Management Information System, then we must look 
at the organization and analyze what files (data) must be present to do the 
systems required or the information that is needed to run the University at 
the operational and management levels. 

A typical breakdown of the files required to support Student Records is as 
follows: 

a. Student Master File e. 

b. Student Course File f. 

c. Master Course File g. 

d. Section Master File h. 

i. 



Grades/Transcripts 
Graduation Sub File 
Student Contract 
Prerequisite 
Student Account 



49 



135 



The Admissions Office will require a Prospective Student File and access to 
the Student Master File to support their office. Alumni/Development need two 
files: a) Alumni Master and; b) Gifts/Pledges. To handle the space require- 
ments for Planning, we need a Space Master File and Property Records. The 
Physical Plant will need a Requisition or Work Order Master File, a Time and 
Activity Master and an Inventory Master File. This subsystem must be inte- 
grated into the General Ledger for charge back. 

The Computer Center requires a Work Order or Requisition Master File, a Time 
and Activity Master File, an Inventory Master File and a Project Management 
Master. The Library requires four files to make it a complete Management 
Information System, namely the Book Catalog, the Patron Master, the 
Circulation Master and the Book Acquisition. Financial Aids must have a 
Student Application and an Awards File, plus access to the Student Master File 
if they are to have a complete system. Human Resources requires five files: 
a Personnel Master, Payroll, Benefits, Faculty Activity and the Budget 
Position File. The Budget Position Master must interface with the Personnel, 
Payroll and Budget Master File. 

In the Financial areas we need a Purchasing, Payables, Receivables, General 
Ledger and Budget Master with access to student files for a complete, inte- 
grated system. Naturally there are more possible files depending on whether 
you have a medical school or auxiliary enterprises. I did not illustrate the 
files needed for the Book Store, Food Service or other auxiliary enterprises. 

HOW TO INTEGRATE THESE FILES BY SYSTEMS 

It is easily shown that in the Student Records area we can register students 
with only the Student Master, Student Course, Master Course and Section Master 
Files. However, we can't check for prerequisites without the Prerequisite 
Master nor can we counsel students 'ithout a degree audit using a Contract 
Master ; ate. What makes the complete, total Management Information System is 
the ability to add these subsystems that support registration (prerequisites) 
and advising (degree audit). Lot's suppose we wanted to perform a degree 
audit; a contract file would be built at the time the student entered the 
college of his or her choice. At grade time, each course attempts in the 
contract file* would be flagged as completed and a list of courses remaining 
could be printed. At degree time, the contract should be completed with no 
courses remaining in this file for the student to comp'* '2. 

The graduation sub-file would be the file of all those students who have 
applied for graduation and this file will be used to pull the courses from the 
grade file and compared to the contract file the term before graduation. The 
graduate sub-file also can be used to determine the line of march and this 
file can be passed to the Alumni system for Alumni processing after 
graduation, etc. I could go on and on showing us how to integrate these files 
into a total Management Information System. 

WHAT'S HAPPENING TODAY 

Today we see a demand for information and one that must be satisfied within a 
short span cf time. Users cannot wait for two or three days to obtain an 
answer to their question. If you have your systems developed using a data 
base language with a retrieved package, you are probably able to meet this 
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demand. If not, you need a fourth generation language like FOCUS or IMAGINE 
to bridge the files and allow you the ability to retrieve the data and not 
have to worry about file structure. 

In effect, the building of a Management Information System requires the System 
Analyst to understand the organization, files and systems required to manage a 
large institution. To accomplish this, a good five year plan should be 
instituted. 

The University of Akron formulated such a plan in early 1986. The strategy 
was to have a five year plan completed by April, 1986. In January, the 
President designated the Director of Computer Services as the Chairman of the 
Computer Planning and Policy Committee, whose body consisted of the Provost, 
Vice President for Business and Finance, one Dean, three faculty members and 
two administrators. The committee was in agreement that computing was too 
broad to look at as one whole entity. We divided the spectrum into six areas: 
1) large academic mainframe computers; 2) mini and micro academic computing; 
3) Computer Based Education; 4) Graphics; 5) Administrative Computing; 6) 
Networking; and 7) Office Automation. Several subcommittees were formed by 
selecting faculty and administrators most knowledgeable from their respective 
areas. The subcommittees interviewed faculty and administrators across 
campus, completing their reports by March of 1986. In April, the plan was 
developed with estimated costs for each area. The total plan was estimated at 
$12 million and today we have spent about $6.5 million. We have implemented 
the large academic mainframe recommendations and are presently working on the 
Office Automation, Networking and Administrative portions of the five-year 
plan. However, any plan requires monitoring and can expect change. We are 
now in our second year of the plan and working on updating the plan. 

This leads us to a second area of concern: What about strategic computing? 



STRATEGIC COMPUTING 
IMPORTANCE OF INFORMATION MANAGEMENT 

Information is one of the basic resources available to managers, just as 
valuable as human, material, or financial resources. It is hard to imagine 
the manager of today functioning without the use of sophisticated information 
management tools. 

INCREASING COMPLEXITY OF THE MANAGEMENT TASK 

Management has always been a difficult task, but it is more today than ever 
before. The sheer size and complexity of the organization requires the use of 
information management systems. The current trend toward factory automation 
and robotics demands an ever increasing dependence on information systems. 

The fast paced nature of today 1 s business environment requires management to 
respond quickly to competitive pressures. Computer based management systems 
are the mechanism that allows managers to respond in a timely fashion. 

All of these factors—size, complexity, technology, and competitive 
pressures- -influence the management task. Information systems have become 
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central to the functioning of management in most organizations. The planning 
and implementation of such systems, can give the organization a competitive 
edge* Strategic, long range, planning of computer based systems is a crucial 
role for top administration. 

AVAILABILITY OF DECISION-MAKING TOOLS 

Even as the manager's tas> has become more complex, there has been a movement 
under way to improve the effectiveness of decision making. Central to this 
movement are quantitative techniques and computers. Terms such as management 
information systems (MIS) and decision support systems (DSS) represent 
currently popular means of assisting the manager with computer-produced 
information. MIS refers to the overall application of the computer in a firm, 
with the emphasis on supporting management's information needs. DSS refers to 
efforts applied in a more focused way — on a particular problem faced by a 
particular manager. 

MANAGEMENT SKILLS 

A successful manager needs to possess both decision-making and communications 
skills. Managers on all levels must decide on strategies, tactics, and 
operations. They also must communicate with persons reporting within and 
without the organization. 

Today most middle managers have received some formal computer training. They 
are becoming more knowledgeable in computer basics and able to communicate 
with the computer professional. These managers and computer specialists can 
jointly develop computer-based systems to solve business problems. The new 
manager has an understanding of the strengths and weaknesses of the computer 
when applied to business problems and are able to use the computer as a 
decision support system. 

EVOLUTION OF MIS CONCEPT 

It was not until the mid-fifties that computers were marketed on a widespread 
basis. Computers were used on a limited scale for processing accounting data 
rather than producing management information. 

During the early sixties, information retrieval was developed. It was 
primarily concerned with storing, retrieving, and displaying information. 
Many of the systems of this era failed because management was overly 
ambitious. Firms erroneously believed that they could build a giant 
information system to support all levels of management. 

The current focus is on decision support systems (DSS) and communications. 
The DSS provides support by actively involving the managers and providing 
analytical software to manipulate a data base. The MIS plays a more passive 
role by providing information that managers must interpret and apply at the 
operational level. 

Since around 1980, interest has been aimed at office automation (OA). These 
systems seek to provide productivity gains through electronic communications. 
Office automation provides word processing, electronic mail, teleconferencing, 
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voice mail, electronic calendaring, document transmission, and other means of 
increasing office productivity. 

The current focus is on the linking of articial (Al) intelligence and expert 
systems to the MIS. AI seeks to provide logical human reasoning by computer. 
Expert systems are a subset of artificial intelligence. Expert systems will 
eventually provide the primary link with DSS. Instead of DSS simply assisting 
the manager, the expert system will be able to suggest alternate ways to make 
a decision. 

ACHIEVING THE MIS 

The manager is ultimately responsible for the MIS. The planning and control 
of information systems requires the involvement of top level management. New 
fourth generation software is easier for managers and end-users to use. This 
user friendly software has stimulated many users to do their own computing 
using on-line workstations. The microcomputer boon; has also fueled this 
intense desire for end-user computing. 

INFORMATION NEEDS OF EXECUTIVES 

Executives are different. An executive is not just a lower-level manager 
working on a higher level. The job changes drastically when the manager 
reaches the top. Top-level managers receive most of their information from 
subsystems. It is necessary to process lower-level data into useable 
information for top management. Any executive information system must take 
into account the special needs of top-level management for summary data as 
well as forecasting trends. 

STRATEGIC COMPUTING 

The increased computer literacy of users and the ease with which users can 
acquire their own computing facilities have made many firms realize the need 
for a new corporate attitude toward computing. It is necessary for top 
management to devise long-range plans specifying information requirements and 
identifying the application of existing technology. Strategic computing 
requires the following ingredients: 

1. The chief information officer (CIO) should report directly to the 
president. 

2. A data administrator should establish and enforce policies and 
procedures on company data. 

3. Information services department should have a documented understanding 
of data flow throughout the organization. 

4. Long-range planning should identify information resource requirements. 

5. CIO should establish organizational wide MIS policies. 
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CONCLUSION 

The combination of a good CIO that can manage data, set long range plans that 
include both the operational and top-level management, provide the capability 
to retrieve information using fourth generation level languages, three 
distribute networks and decision support systems is the basis for strategic 
computing. 
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STANFORD JUMPS TO THE 'WS 

DISTRIBUTED PROGRAMMING 

PROMISING OR PREMATURE? 

David J. Ernst 
Stanford University 



The paper outlines the growth and success of Stanford's centralized 
administrative systems programming organization, Information Services, over 
the past five years and the unique turn of events which have led to its 
decentralization into client offices during the latter half of 1987. Key 
reasons for the growth of the organization including joint reporting 
relationships with clients, a focus on building service and quality from the 
grass roots level, use of modern programming techniques, and an early and 
strong commitment to meeting the needs of campus departmental units are 
discussed. Of special interest is the way in which all of these attributes 
led to a predicable decentralization in the early 1990 f s which was accelerated 
during 1987 because of unforeseen factors. The challenge ahead for Stanford 
is to manage the problems created by this relatively sudden change in such a 
way as to "get a jump 11 on how to keep information systems functions in tune 
with client and technological requirements for the next decade — the "promise" 
of the distributed programming model. 
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I. INTRODUCTION AND OUTLINE 

What I present here is a review and analysis of recent events at Stanford 
University in the information systems arena. It Is a study that I believe I 
have a professional obligation to present to this group of interested peers, 
but, I must admit, I would rather be listening to one of you tell about how it 
happened somewhere else! Let me begin, then with "Stanford Jumps to the 
90 f s— Distributed Programming, Promising or Premature?"— or, as an alternate 
title: New mail on node VAXF from CUBLDR: :PATTEE_D "Donna" "Stanford f s 
Second Major Earthquake!" 

During the course of this paper I will cover the following major areas: 
— The Information Services Environment at Stanford in the 80 f s 
— Key Milestones in I. S. Evolution Since 1980 
— Changes in the Air— Early 1987 
— Decisions Made and Directions Set 
— Implementing the Decentralization Plan 
— Prognosis for the Future 



II. THE INFORMATION SERVICES ENVIRONMENT AT STANFORD IN THE 80' S 

It was clear by the late 70 f s that Stanford needed to overhaul its core 
administrative applications both to better meet client needs and to take 
advantage of new information technology. Thus, by 1980 the university had 
decided to proceed with major new development in the financial, student, and 
al umni and development areas. A search wa? also launched for a Director of 
Administrative Information Systems with a administrative user background 
rather than with a technical one. 

The demand for more (and more articulate) "user involvement" was very strong. 
The existing Administrative Data Processing Services unit had an only 
partially-deserved reputation for taking too long to deliver applications and 
costing too much. The sense was that by the time ADPS delivered a product the 
client's needs had changed and he couldn't afford to pay for it. Users 
demanded to be more a part of the development process. 

Greater flexibility in the systems design process with better modification 
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capability was essential. The concept of "iterative development" was emerging 
and being adopted at Stanford. This, coupled with the selection of a fourth 
generation data base management system with which to do all of the new 
applications development addressed both the flexibility and modification 
capability issues. 

Another factor in the information services environment was the change in both 
the number and nature of IS clients. The traditional central administrative 
office clients like the Controller's and Registrars offices were playing very 
active roles In the design and development process of their new applications. 
There was strong emphasis on the value of information and how it affected the 
quality, service, and productivity of the central offices. In addition, a new 
set of clients was surfacing as the departmental unit, both academic and 
administrative, came to be recognized as the real initiator and ultimate user 
of administrative data. At the same time the individual, particularly one 
with a terminal or PC, was seen as yet a third type of client, distinct from 
both the central office and the department. 

By the latter half of the 1980 f s the departments had become an extremely 
strong factor in influencing the priorities of central administrative offices 
and of IS* They soon realized that the millions of dollars spent on "central 
systems" development in the previous five years hadn f t given them all that 
they needed at the "departmental" applications level. The departments were 
ready for "their fair share" and weren f t at all sure they would get it if it 
were to come out of the central computing organization. 

III. KEY MILESTONES IN I.S. EVOLUTION SINCE 1980 

In January of 1980 the Center for Information Technology (CIT) was formed to 
provide a single campus focus for all computing and Information technology 
activities. Its formation indicated a strong commitment by university 
management to promote these functions via a single, central organization. 

Early in 1982 the Administrative Information Systems (AIS) organization (as IS 
was called then) which was a part of CIT reorganized to reflect Stanford's own 
admistrative structure. Thus, AIS had units responsible for the Controller's 
Office, student systems, the Alumni and Development Office, the Hospital, etc. 

In addition, the unpopular hourly programming rate was abolished and replaced 
with detailed annual budgets for each client area with clients paying for AIS 
services on a monthly basis according to the agreed-to budget. Another 
successful organizational strategy was the concept of joint reporting 
relationships where AIS Assistant Directors reported jointly to the AIS 
Director and to the head of their client area. For example, the Assistant 
Director for Financial Systems reported both to the Controller and to the 
Director of AIS. Borrowing from the legal concept of joint tenancy, each 
supervisor "owned" all of the Assistant Director. The Assistant Director 
would, in turn, supervise programming staff in the Controller's Office and in 
AIS. Since both staffs had the same "boss," much of the "we/they" attitude 
went away. 

Later in 1982 the Stanford-developed SPIRES data base management system was 
chosen as the principle DBMS for development of the new central administrative 
applications. This decision came after months of study of the alternatives 
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and a firm conviction that a single DBMS in a "fourth generation language" 
would provide the best system integration, speed the development process, and 
involve the users to the greatest degree possible. At the time SPIRES and 
FOCUS were ranked similarly in the Stanford study, but in the end SPIRES was 
chosen because the staff supporting it were already in place on the campus and 
the future direction of SPIRES could be determined locally. 

At the end of 1982, it was evident that some guiding principles were needed to 
integrate the several major development efforts that were going on 
simultaneously and to focus the campus on the ways in which administration at 
all levels could and should change once the new applications were in place. 
The "Administrative Systems Architecture" became the guiding concept around 
which the development effort took place. The Architecture was simple, easily 
understood, and in some ways, very subtle. At its center was the departmental 
unit surrounded by the central administrative offices with the whole connected 
by campus electronic networks. The basic tenent was that the department, both 
as originator and ultimate user of most administrative data, was the most 
important client of all. The department -and its growing local computing 
capability had to be recognized as having perhaps the most critical stake in 
the so-called "central systems development." This fact, coupled with the 
growing realization that central administrative offices exist primarily to 
serve departments and not vice versa, influenced the way in which the new 
development was done and continues to influence today's information technology 
at Stanford. Although in some ways simplistic, the Architecture served to 
focus both technologist and line officer alike on the fact that the new 
development and the efforts that came after it had much less to do with 
computing than it did with the way in which people do their day-to-day 
administrative work. 

1983 marked the beginning of the shift away from a single, large information 
technology organization to manage all of Stanford's efforts in this arena. In 
a move to bring "academic computing" closer to academic administration, 
academic computing consultation and academic networking support were shifted 
from the CIT organization and placed under an Associate Provost. CIT became 
ITS, or Information Technology Services, and inherited both Telecommunications 
and Graphics and Printing Services. While the Director of CIT reported to the 
Provost and two Vice Presidents, the Director of the new ITS (the same person, 
by the way) reported to the Vice President for Business and Finance and ITS 
became a part of the Business and Finance organization. 

As personal computers proliferated on campus and the needs of departments 
became more evident, a group of professionals was organized in IS to provide 
support to departments at least commensurate with that being supplied to 
central administrative offices. This unit of IS was called Departmental 
Information Services (DIS) and was formed in 1984. DIS did extensive surveys 
of campus departments including several in depth studies of specific 
departments to assess and rank departmental needs and establish DIS staffing 
priorities accordingly. Over time DIS became expert in providing consultation 
and support to departments and individuals in the information technology 
arena. The group became the leading advocate for departmental and school 
information services support and continued until its elimination in 1987 to 
operate with a large backlog of consultation requests. 

As the new applications development proceeded the need for a common user 
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interface came to the surface. While one set of commands used to access 
student data all day by an employee in the Registrar's Office was workable, a 
staff member in the Biology Department needed access to student, financial, 
purchasing, and alumni data all in a day's work. On-line access commands in 
each of these applications could differ widely even though they were all 
written using SPIRES. Thus, for most departmental employees different sets of 
commands would have to be learned for each application if they were to use the 
new systems. To overcome this problem, a single set of menu- driven commands 
was developed to cut across all major applications to facilitate use primarily 
at the department level. This interface, called "Prism," was introduced in 
1984 and is widely used today at Stanford. 

In 1985 development on the new applications was far enough along for the 
campus to begin testing departmental on-line entry and access to several kinds 
of data used in departmental administration. The Departmental Access Pilot 
Project was begun to open up access to several departments at no cost to them 
to gather data on what would be required to provide entry and access to all 
campus departments within the next few years. The pilot project resulted in a 
great deal of important data on costs, training requirements, and technical 
issues which formed the basis for planning the implementation of full access 
by the end of the decade. This would mark the ultimate implementation of the 
Administrative Systems Architecture. 

3y 1986 concern was growing among the central administrative offices that the 
new applications were costing more to run than they had anticipated. Most of 
the energy and attention related to budgeting for the new applications had 
focused on allocations for the development costs and, while several accurate 
projections had been made in 1982 on future operating costs, no one had paid 
much attention to them. As client computing budgets were overrun, fingers 
were pointed and scapegoats were sought, but the end result was a call for 
major cost reductions. Since most of the overspent budgets were for ITS 
computing charges, the principle target for cost cutting became the ITS 
organization. Ironically, DIS, which was funded almost totally from ITS 
mainframe revenue, came under heavy attack while providing some of the most 
popular ITS services to the growing departmental clientele* In the end, the 
political pressure was too great and DIS was sacrificed in August of 1987. 
Much of the time of the senior leadership of ITS from early 1986 until the 
organization was disbanded in mid-1987 was spent in budget reviews aid program 
defense rather than information technology. Just how much was lost of the 
leadership role Stanford developed in this area in the five previous years 
during that 18 month period remains to be seen. 

IV. CHANGES IN THE A IR — EARLY 1987 

Sometime in late 1986 or early 1987 the Stanford Provost reportedly began to 
examine the idea of pulling all information-related resources together under 
a new vice presidential organization. In this plan the ITS functions, those 
split off from CIT in 1983 and placed under an Associate Provost, and the 
Stanford University Libraries would be combined. The concept of including the 
libraries was not new, of course, given the experience at Columbia and 
elsewhere, but it had not been considered seriously at Stanford in the recent 
past. Rumor had it that the Provost thought the idea made a good deal of 
sense, but did not want to make the organizational move unless the libraries 
would go along. Apparently, he also did not believe that a new vice presidency 
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could be justified with only the ITS and Associate Provost areas included. 
Only a small circle of people knew the idea was being considered until early 
February when it became more widely known and some opposition began building 
in the libraries. 

The Provost had also begun a gradual shift of reliance and emphasis from the 
Business and finence organization. More and more staff work that had 
traditionally been done in Business and Finance or shared between that 
organization and the Provost's Office was now handled by the provostial areas. 
Long-time Stanford watchers noted the change to more symbolic and real 
management on the institution by the faculty and academic administrators. 

By 1987 ITS was under heavy pressure to reduce its budget even after having 
made multi-million dollar reductions in 1985 and 1986. Lay offs were being 
considered and morale was at an all time low. More importantly, as far as the 
future of the organization was concerned, ITS was becoming a major liability 
to Business and Finance which had already witnessed its own star dimming. The 
fact that ITS was ultimately disbanded is as much attributable to its lowered 
status and reputation as it was to the Provost's desire to pursue the idea of 
a new vice presidency. Had ITS been a strong and popular organization within 
Business and Finance, it probably could have survived particularly given the 
fact the the libraries effectively kept themselves out of the Provost's plan. 

Actually, the "downsizing" theme had been rolling across the campus for some 
time beginning with the Hospital in 1985. ITS was not alone in its budget 
cutting and other areas in Business and Finance were affected as well. Early 
in 1987 the concept of "smaller is better" seemed to be the most popular 
bandwagon making one wonder if some of the early ideas of the "junior Governor 
Brown" had acquired a new following. 

V. DECISIONS MADE AND DIRECTIONS SET 

In mid-March I met with the Vice President for Business and Finance, Bill 
Massy, and he said that he had just come from a meeting with the Provost and 
the establishment of a Vice President for Information Resources was a virtual 
certainty. The libraries would participate only to the extent of a 
coordinator in the new Vice President's staff, but ITS in its current form 
would be fully subsuwbed by the VP-IR organization. The official date would 
be around July 1. 

All of this information was basically known by most of us at this time and the 
meeting with Dr. Massy merely made it official. What he said next, however, 
came as a complete surprise. He told me that he believed it was probably time 
to split, up IS as well and distribute the several programming groups to the 
central offices for which they provided service. His reasons centered around 
his belief that the new VP-IR did not have administrative computing high on 
his priority list and if IS were to become a part of IR, it might be 
neglected. He also stated that the clients probably wanted to get "their" 
programmers back at this point anyway. Massy said that although he was 
interested in my thoughts on the issue, he just could not see any good reason 
for holding the group (IS) together. I think this group of listeners won't be 
surprised when I say that my views diverged from those of the Vice President! 

My initial reaction at this meeting with Dr. Massy was that I knew of no 
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client who wanted to supervise programmers and none were less thai satisfied 
with the service they had been receiving from IS. As to the point that IS 
might be neglected in the new IR organization, I noted that we were basically 
self-sufficient anyway and had never relied on strong supervision from above 
or a collection of other technology-based organizations around us for success, 
much less survival. For that matter, if there were a concern for IS being a 
part of IR, why didn't Massy just keep us since we were still at that time a 
Business and Finance entity? I did agree to take the next two to three weeks 
to interview all our clients, most of the IS staff, and talk to some of my 
colleague IS H -fre^o** 0 at- oth^** *«tt-**»«e *e t ~ i i ~ *. »..,.. .t. 

with what was really going on with my own organization. 

On April 26 I completed my review and reported back to Dr. Massy in a paper 
entitled: "The Role, Function, and Organization of Information Services." In 
a nutshell, I found that all of our clients believed that IS had served them 
well in the past and was continuing to do so. The weakest support came from a 
client who said that the plan to decentralize IS probably could work. The IS 
staff and many ITS staff who worked closely with us, were adamant about the 
need for the organization to stay as one. Many were curious as to why a 
functioning, well-run, and basically well-respected organization was being 
considered for demise. One staff member quipped: "It sounds like someone is 
saying: °It f s fixed, let's break it!'" My discussions with other IS directors 
yielded surprise and concern that Stanford to whom many had looked for 
leadership in the IS arena, seemed to be bowing out of that position. 

My primary recommendation to Vice President Massy was that IS stay together as 
one organization either within Business and Finance or moving into the new IR 
organization. Some of my reasons for this recommendation were: 

— the economies of scale resulting from a single IS organization are 
significant and can be measured both in dollar and productivity 
terras 

— programmers are more productive and effective as part of a larger 
professional peer group where ideas can be traded easily, organiza- 
tional loyalty develops, and several career paths are available 

—IS is in the height of its success, liked by its clients, with a 
devoted and loyal staff, and respected by its peer IS groups 

— IS has remained within or below its budget for the past six years 
and, in fact, turned money back to its clients 

— IS clients don't want "their programmers back" 

— a better time ror decentralization of IS would be in the early 90's 
when the systems development is completed and departments are fully 
on line 

I concluded my report to Dr. Massy with the following: 

Information Services, in the spring of 1987, finds itself 
betwixt and between. Its people have worked hard to 
achieve the ability to facilitate, not hamper the business 
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of Its clients and to do so while being as "invisible 1 as 
possible. It would be an unfortunate irony if IS has been 
so successfully invisible as to be considered unnecessary 
as an organization. This is not a view held by IS and, more 
importantly, it is not held by IS clients. 

Vice President Massy committed his own thoughts to writing in a "Talking Paper 
on Administrative Computing Reorganization 11 in early May and used that as a 
basis for his own set of interviews with IS clients, staff, and others. He 
evaluated the then-current situation and had these findings: 

major administrative applications are nearly complete 

—support for departments is critical, but progress has been unsatis- 
factory because "do-it-yourself 11 groups have sprung up to try and 
provide support 

—there has been a lack of high-level (meaning vice and sub-vice 
presidential) attention to the business problem of local and 
central systems connectivity 

—there .is a need for comprehensive stratigic thinking, planning, 
and cost-benefit analysis for administrative systems and their 
role in productivity enhancement — this is a business, not a 
technical issue 

The basic conclusions reached in the Massy paper were stated as: 

* It is no longer necessary for applications 
programmer/ analysts to report to a centralized 
technical organization in order to achieve 
acceptable technical outcomes. Decentralization 
of this function will enhance the focus on business 
issues snd also eliminate much of the overhead of 
the central organization. 

* Administrative system planning and development is 
part of the fabric of the line operating function. 
It cannot be effectively delegated to a centralized 
technical or information organization. (Of course 
the central organization can facilitate the 
process, as described below.) Line operations 
lacking in local understanding of administrative 
system principles and capabilities should develop 
appropriate internal resources as soon as possible, 
or else make arrangements for organizations with 
similar work processes to assist them. 

* Strategic planning and oversight for administrative 
systems should be university business functions. 
Concentration should be on what work is needed and 
how it is to be performed, rather than on the more 
abstract concept of "information." This function 
should include determination of the scope and focus 
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of our various administrative systems, the 
boundaries between them, verification of the 
"ownership 11 of each system and the responsibilities 
of the owner, and the adjudication of data access 
issues where necessary. 

* Not-with-standing the above, administrative systems 
planning, development, and refinement must continue 
to be closely linked to and well supported by 
technical and information resources. 
University-wide peergrouping of applications 
programmer/ analyst personnel must be nurtured and 
utilized effectively; this function is best done by 
the new Information Resources organization. 



A new organizational structure was proposed in the "talking paper" and 
discussed with clients and staff of IS. The key points of the new structure 
were: 

— IS would be disbanded and the programmer units distributed to the 
line organizations 

— the Software Acceptance and Quality Assurance unit would move to 
the Data Center in IR 

— the administrative systems strategic planning function would move 
to the Vice Presidents office in Business and Finance 

— a process would be established to facilitate programmer-analyst 
"peer grouping" 

— a "Front Line Departmental Systems Group" would be established to 
develop, maintain, and enhance departmental administrative 



— an "Administrative Productivity Council" would be formed to 
provide policy level leadership 

After further discussion with clients, staff, and me Vice President Massy 
announced publicly on May 19 that he had decided to proceed with the structure 
he outlined in his talking paper. 

I am reminded of a question from the audience during a panel discussion in 
which I participated at the Snowmass Conference over the past summer. I had 
been giving an abbreviated version of the contents to this paper to bring 
people up to date on what was going on at Stanford. A gentleman stood up and 
asked me how I knew it was time to decentralize IS at Stanford. I told him I 
knew because the Vice President for Business and Finance told me so — twice! 
May 19, 1987 was the second time. 

VI. IMPLEMENTING THE DECENTRALIZATION PLAN 

A transition team to implement the IS decentralization was formed in June and 
charged by Dr. Massy to complete the process by December 31. Members of the 
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team were the Director of the (new) Stanford Data Center, a staff member in 
the Business and Finance Management and Financial Planning office, and the 
Director of IS. We met weekly through August to deal with the transition 
issues and to keep the lines of communication open both within IS and between 
IS and other concerned organizations — particularly client organizations. 

Several key issues arose during the transition period that are worth noting. 
First, in the budget area, we had to determine if the funding available to 
support IS in its centralized mode would be adquate to provide support to the 
several decentralized units. In addition, the new functions (strategic 
planning, "front line systems" and the like) outlined in the Massy paper had 
to be costed. Then, there would be the computing charges from the Stanford 
Data Center for 1987-88 that had not yet been estimated. All of these costs 
would have to be summed and compared to the known existing funding including 
the amounts previously used to fund the IS Director and his office which would 
M go away" under the new plan. 

In the personnel and staffing arena, the principle issue was the determination 
of which staff would go with which client area. It wasn't as simple as just 
dividing up people based on the IS division breakdown because many programmers 
were split between two or more cost centers. Eventually we settled on 
distribution based first on the foreseeable maintenance and development needs 
of the several client areas matched against criteria of skill set mix, 
critical mass, and simple equity. Another issue was the spectre of layoffs as 
we tried to make sxxce all programmers and support staff were placed, but had 
no assurance that some wouldn't "fall between the cracks." Finally, we faced 
the need to announce all staff changes at the same time so that information 
about people's fut ures wasn't trickling out little by little. In the end, we 
announced a date upon which all IS staff would learn to whom they would report 
and where they would work. 

Space was another issue that required our attention as the Massy paper called 
for the programmers to be located with the clients for vhom they would be 
working. First we had to determine the requirements based on the programmer 
distribution plan and then evaluate the space available in the client areas. 
Needless to say, this issue was placed on the "back burner" until other items 
were settled. Space on the Stanford campus has the same volatility as it does 
on other university campuses! 

Finally, and most importantly, were the morale issues. The IS staff was 
extremely agitated with the decision to proceed with decentralization. These 
concerns were building in intensity daily and it was essential that 
opportunities be provided for staff to express their concerns on a regular 
basis. The opportunities were made available for both public and private 
expression and interchange with a person or persons who knew what was the 
current situation. We worked hard to keep the information about the 
decentralization process flowing to the staff in electronic mail messages, 
through supervisors in staff meetings, and in regular social gatherings. The 
key was to keep the focus on the future and not let the general desire to hang 
on to the IS of the past postpone the inevitable. By maintaining a high 
visibility and availability of the IS Director and his Assistant Directors to 
the staff, severe productivity losses were avoided. Still, most of the summer 
of 1987 represented the lowest ebb in the output of the IS staff. Offices in 
the IS building that normally had lights burning well into the evenins and on 
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' aekends too, now were dark at 5 and rarely occupied on weekends. Staff 
morale was probably the single most important Issue dealt with during the 
transition period. 

The status of the IS decentralization in December of 1987 is that it is 
basically complete. The organizational and budgetary changes were 
accomplished on September 1. The IS staff is still occupying the same 
building with no new space to move to for at least one year. The Director's 
Office staff who were not transferred to client areas all have found new jobs. 
No layoffs were necessary and no one quit. Basically the consolidated IS 
budget was adequate to fund IS-type functions in the client areas and some new 
dollars were made available to fund the strategic planning and "front line 
departmental systems 11 initiatives. No action has yet been taken on the 
"Productivity Council." The IS organization will cease to exist, on schedule, 
on December 31, 1987. 

VII. PROGNOSIS FOR THE FUTURE 

The events of 1987 are wuch too recent and, in fact, the results are still 
unfolding for any accurate post mortem to be done at this time. I believe it 
is much more important to focus on trends which led up to the IS 
decentralization than to worry about whether the same thing will happen on 
your campus. These trends and the way in which they are addressed can have a 
major impact on the role and the vitality of your IS organization, and, for 
that matter, of your institution. 

First is the strong need to integrate the business functions with the 
applications supporting them. There is not the "work of the Controller's 
Office" and the "financial system." They should be one in the same or at 
least have that as the goal shared by the programming and the functional 
staffs. 

Secondly, is the tendancy of some clients to let the IS staff make the 
decisions on how best to make the application support the business functions. 
We found that the point can actually be reached where a client and programming 
staff are so well integrated that the technical group may be "calling the 
shots" in some parts of the client business. It is an ironic twist from 
several years ago when we were all admonished to "learn the client business" 
and don ! t "talk techie" all the time. Many would argue that this degree of 
client/technical staff integration is admirable, bur the lesson is not to let 
it be perceived as the client shirking its responsibility. 

Third is the absolute necessity to pay attention to the schools and 
departments. Inevitably they will emerge as the prime force driving 
administrative systems and those responsible for them. IS at Stanford started 
chanting that theme (and doing something about it) in early 1983 and we could 
have done even more. 

Finally, and perhaps most importantly for you IS types, is the need to develop 
a role for the IS organization beyond that of a simply technical group. The 
IS of the future will need to focus on the nature of administrative work and 
how information systems can make a difference in improving productivity and 
"working smarter" in client areas— especially departments. 
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There are several questions that will remain unanswered for some time as life 
m a decentralized environment evolves and evaluation of the results of the 
management decisions of 1987 begins. Some of these questions worth watching 
cit*e ♦ 

—Will good programmers continue to work in an environment where the 
peer group has gone from 90 to 9 or less? 

—How key was the existence of a strong, central IS organization to 
systems sharing, standards adherence, client coooerat<on and the 
like? ' ' 

—Will the "smaller Is better" concept truly allow for coordinated, 
integrated approaches to meeting departmental information needs? 

—Will the decentralized approach save dollars across the University 
or will all the new pieces add up to more than the orginal whole? 

In closing, let me briefly state mv personal opinion on the situation with IS 
at Stanford. My speech is titled "Stanford Jumps to the 90's" because much of 
the decentralization put into place over the past six months we had intended 
to do in the early 90 's anyway. I do think, though, that we "jumped" too 
fast. My title also asks the question "Distributed Programming, Promising or 
Premature? Simply put, I believe that distributed programming at St ai ford 
University as instituted in 1987 is a promising idea prematurely implemented. 
But, then, that is only the personal opinion of one, soon to be emeritus 
Director of Information Services. ' 

As they say, "only time will tell" and the only fair way to end this story at 
this point is not with "the end," but with: "to be continued " 



153 



THE DIRECTOR DONS THE BANKERS CAP 
or 

NEED A PC? HAVE I GOT A DEAL FOR YOU! 



Arthur Brooks 
University of Missouri - Rolla 
Rolla, Missouri 



With the introduction of the Personal Computer to the busi- 
ness world, images of a magical work producing box danced through 
the minds of the University departmental directors. At no time 
had a single piece of business equipment created such a near 
instant demand. The wondrous new computers dangled before the 
administrator's eyes like the golden ring on a merry-go-round. 
However, with budgets which barely met current office obliga- 
tions, the new devices were well beyond the financial reach of 
most departments. In 1985 this campus of the University of Mis- 
souri instituted a self-funded Personal Computer loan program 
which allowed the departments to purchase PCs and repay the money 
over a forty-two month period of time. This paper describes the 
process created to manage the fund and relates the experiences 
gained from the program which is nearin*. the end of its third 
year of existence. 
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When the IBM Personal Computer was realized as a potential busi- 
ness tool in the early part of this decade, the University of Missouri 
- Rolla administrative departments were faced with a serious problem 
Everyone seemed to want one of the ne»> magical boxes, but very few 
people had the funds to finance the purchase. While the prices were 
attractive, the amount was simply more than any departmental budget 
could afford. As for fully justifying the purchase, no one really 
knew how they were going to use the new devices, they just knew they 
had to have one. To the departments, the new Personal Computers 
provided a sense of freedom from the dependence they had on University 
mainframe computers and computer programmers. This n>w device sua-" 
denly became a way to handle all of the office duties. No longer 
would they have to endure the routine of having their requested report 
put on a work priority by the computer center director. Then they had 
to wait while the programmer defined the report, wrote the program and 
finally produced the results. None of this seemed really necessary -o 
the typical administrative user and it was a process the administra- 
tive user wished to eliminate. In the eyes of most directors, one of 
the new Personal Computers would save the department money, time, be 
more efficient and the results would impress their superiors. Who 
needed those computer people anyway? 

Consequently, during the first year or two, there was a mad 
scramble to secure monetary assistance to buy PCs. Scarcely a depart- 
ment had the funds to purchase the desired equipment from their own 
accounts. They needed to seek the financial support of a higher level 
administrator. These administrative benefactors found their desks 
cluttered with proposals for the purchase of Personal Computers for 
the benefit of campus departments. With insufficient funds to satisfy 
all requests from campus units, these higher level administrators 
chose the proposals they determined to be in the best interest of the 
campus or their own administrative area. From this activity developed 
two distinct camps, the 'haves' and the 'have nots.' The fortunate 
group of campus units embarked on a flurry of activity with their 
new \ acquired micro computers. They were too mired in the business 
of how to work these new tools to worry about the productivity of the 
machines and the reality of their ambitions. On the side lines, the 

have not camp sat and watched the flurry of activity with much dis- 
may. Ii only they had been chosen 

^Anp^ ^L°J the Director of Administrative Data Processing 

(ADP) at UMR submitted a proposal which entertained the idea of desig- 
nating a specified amount of campus money for the procurement of Per- 
sonal Computers for campus administrative units. The concept was not 
a particularly new idea for other universities, but it was new to the 
University of Missouri. This plan was targeted to assist those campus 
departments who were currently renting computer terminals from the 
Computer Center, campus administrative divisions who had computer 
equipment rental as part of their existing budget. The desire was to 
be able to present to the administrative units an opportunity to 
replace their computer terminals with newer equipment while maintain- 
ing a near constant departmental budget. With this in mind, it was 
init:. iUy proposed the funds be made available to campus units on a 
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thirty-six month loan basis. The loans were to be repaid on a yearly 
basis, with a nominal interest being charged. By this approach a sub- 
stantial portion of the f have not 1 camp would be satisfied and the 
campus productivity, hopefully, would increased. The following argu- 
ments, supporting the self-funded loan concept, were presented to the 
Chancellor: 

1. The number of departments purchasing PCs would increase, 
thereby addressing the Chancellor 1 s stated <" sire to signifi- 
cantly boost the campus administrative competing activity. 

2. In three years the Chancellor could receive his investment 
back, with interest. (A change from his funding equipment with 
no monetary return.) 

3. Through time payment budgeting the departments could establish 
a method to extend thair office configurations or upgrade their 
computer equipment when the current obligations were met. 

4. The Chancellor could be assured this collection of departments 
would not be approaching him in a few years with requests for 
additional funds for PC replacements. 

5. No departmental budget increases would be required to .implement 
this plan. 

In January, 1985, the Chancellor of the Rolla campus committed a 
sum of $70,000 for the use of purchasing Personal Computers for admin- 
istrative departments. The details of the restrictions associated 
with the administration of this account was left to the discretion of 
the Director of Computing Activities - Rolla and the Director of 
Administrative Data Processing - Rolla. After due consideration it 
was determined by these two individuals that the users would repc*y the 
money on a forty- two month basis. There ^s a concern expressed 
regarding the users experiencing hardware difficulties and being faced 
with having to pay the cost of the repair. Of particular concern was 
the thought that some borrowers might attempt to return the PC to the 
campus computing entity rather than bearing the cost of repairing the 
device. At that point in f\ne, the two individuals responsible for 
the fund were still not totally convinced the new devices would prove 
to last beyond the fad stage. Neither individual wished to accept the 
return of a device which they were not sure they could re-sell. 
Consequently, a monthly maintenance was included in the repayment 
schedule. While there was concern this item would increase the 
monthly repayment rate too much, it would handle the problem of PC 
repair. It was also stated with the early PC fund borrowers that the 
PCs were the property of the individual departments and the computing 
office of the campus would not accept the return of the equipment. 

After considerable discussion the Director of Computing Activities 
and the Director of ADP established the policy that the loan fund bor- 
rowers would pay 13% simple interest and 16% for maintenance. Using 
these figures, a monthly loan payment amount was derived. Not wanting 
to deal with monthly statements, the Director of ADP, who was desig- 
nated as the loan fund administrator, established the policy that all 
repayments would be made only once during the fiscal year. The 
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departments obligation was to start with the first full month after 
the PC was delivered and the departments obligation was due immedi- 
ately for the current fiscal year. For each successive year s the PC 
time purchase repayments would be made at the beginning of the fiscal 
year. It was contended this procedure was in the best interest of 
both the fund and the department. If the University were to reduce 
budgets after the start of the fiscal year, the loan fund would not 
bear the effects of such cuts and the department would have protected 
their time payment obligation. This is a procedure which remained in 
effect for only the first year. Since that time the re-payments have 
been handled anytime during the fiscal year the department wishes to 
process the paper work. These payments have more frequently been paid 
at the end of the fiscal year. 

A formal repayment schedule and loan stipulations statement were 
submitted to the borrowers with the first few purchases. Those stipu- 
lations included such statements as: 

1. All payirants w ere to be paid at the beginning of the fiscal 
year. 

2. The PCs could not be returned to the Computer Center. 

3. The devices were the property of the borrowing department. 

4. If the borrower wished to sell the PC, the Administrative Data 
Processing department would a ttempt to help the department find 
a buyer, but ADP would not accept any responsibility for the 
device. 

It was felt such statements were necessary for the computing 
entity of the campus as the micro computers in the office had not yet 
become a proven reality. The computing directors believed the comput- 
ing entity had to afford itself some sort of protection from those 
departments who launched themselves into an area which they could not 
maintain. Obviously, there was a note of pessimism regarding the per- 
manence of the PC in the office. 

For a department to utilize this fund, the Director of ADP 
requires the potential borrowers to contact him with their needs for a 
Personal Computer. After determining the departments desired config- 
uration, the ADP Director informs the department of the cost of thu 
configuration they had jointly identified and the loan stipulations. 
Upon confirmation of the departments desire to time purchase a Per- 
sonal Computer, the Director of ADP creates the proper University pur- 
chasing documents to purchase the defined configuration. In some 
instances the Director has been able to submit a single equipment bid 
for several departments, resulting in the University receiving lowe*. 
component prices. Upon arrival of the equipment, the Director 
arranges for the installation of the new equipment by the campus Com- 
puter Center. All cost for equipment shipment and installation are 
borne by the time payment account. 

Prior to the establishment of this program, the campus Computing 
Center had established a Personal Computer repair effort. It is this 
operation which is expected to perform all local maintenance efforts 
on the loan fund sponsored equipment. In order to identify time pur- 
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chase equipment when user departments call for PC repair, a label has 
been printed and placed on each time purchased system unit. On that 
label is printed a unique ADP equipment ID code, and the date mainte- 
nance is to expire (forty-two months from the date installed). When 
the campus technical staff repair a time-purchased PC they note the 
number on the label and forward the repair bill to the Office of 
Administrative Data Processing for payment. To this date this system 
has worked effectively. In the event the micro-computer technical 
department automates its inventory system, a bar code is included with 
the PC label. 

In the last two years, an interesting spin-off from this loan fund 
has been observed. Being a public University, the campus departments 
are provided a fixed budget to be used curing the current fiscal year. 
By state law, no campus account may have an end of fiscal year balance 
other than zero, except for specially approved revolving accounts. 
Positive balances in campus accounts are used to cover negative bal- 
ances in other departments. It is left to the discretion of the 
director to see the departmental funds are appropriately used during 
the fiscal year. Upon the approach of the end of the fiscal year, 
campus administrators have traditionally scrambled to balance their 
department accounts. In years for which a surplus has been antici- 
pated, this activity has meant the director had the luxury of purchas- 
ing some less essential items for the benefit of the department. In 
lean years this activity has meant a scrambling to find funds to cover 
departmental deficits. 

Since the creation of the loan program, the departments on this 
campus, who have utilized our time payment account, have had greater 
flexibility in balancing their accounts. If they have monitored their 
spending activity judiciously enough to have an anticipated positive 
balance, some administrators have submitted an extra payment to the 
loan fund tc pay for a portion or all of next year f s PC obligation. 
Those directors who have been faced with a potential deficit have been 
allowed to place their PC repayment in hold for the current fiscal 
year. We have, therefore, seen a more creative form of departmental 
budgeting and have provided the campus with an alternative method for 
dealing with departmental fiscal year-end deficits. 

To this date a number of the devices purchased during the first 
year of this fund have been paid in full. As they have paid off their 
time purchased equipment, some of the departments have purchased other 
devices, thereby keeping their departmental budget at a constant level 
while increasing the number of computers owned by their department. 
It was this very type of activity which had been envisioned when the 
loan program was initiated. 

When this fund was created it was anticipated the PCs purchased 
would have no street value at the time of the loan maturity. It was 
not necessarily a pleasant thought, but one which the administrators 
of the fund felt at the time to be realistic. The advancement of 
technology during the last several years has been such that the value 
of most mainframe computers is a trifle portion of the original amount 
when the organization considers selling them in order to purchase 
newer machines. Considering the initial cost of Personal Computers, 
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the expectation was the micros would have to be viewed as disposable ♦ 
They would have no market value when the loan matured. 

It came as a substantial surprise this last spring when it was 
realized the old PCs did have a value. With the introduction of the 
new IBM PS series computer, the oli PCs suddenly seemed to have an 
identifiable demand. There were departments on campus who had desires 
for purchasing a micro-computer, but did not feel they had the funds 
to buy a new one. Since the Personal System computers were priced at 
nearly the same price as the PCs of two years ago, some of the current 
PC owners were interested in purchasing the new devices if they could 
sell their current PCs. It was in this manner the Director of Admin- 
istrative Data Processing suddenly found himself cast in the role of 
PC broker. An amount of roughly one third of the original purchase 
price was established as the price of a fully configured used Personal 
Computer. Those departments wishing PCs were excited at the prospects 
of obtaining a computer at that price. To safeguard the used PC 
buyer, all used PCs have one year of maintenance paid on the machines. 
The departments owning the PCs were elated at the possibility of 
upgrading their equipment at nearly the same original cost with a 
bonus down payment from the sale of their existing PCs. While the 
sale of used equipment has not reached large proportions, it has been 
successful in the eyes of all participants. 

After two and one half years of existence, this fund has purchased 
over $200,000 worth of equipment for campus administrative departments 
and has a balance of more than $18,000. With those funds the campus 
has purchased forty-seven Personal Computers, three terminal control- 
lers, five terminal multiplexors, upgraded the memory of thirty PCs in 
one of the campus 1 PC laboratories and procured several other miscel- 
laneous items for use in the campus administrative computing effort. 
The equipment on rent today has a purchased value of $112,000. With 
statistics such as this, one must conclude, this initial investment of 
$70,000 has been effective for the Rolla campus. 

In reflecting back on the arguments submitted to fund this pro- 
ject, the following observations could be made: 

1. Upon his arrival to this campus the Chancellor observed the 
lack of computer terminals in existence in administrative 
offices. He did not state a terminal on ever desk as a spe- 
cific goal, but made clear his desire to significantly improve 
the situation. Through the implementation of this fund, the 
Rolla campus has greatly improved upon the ratio of computer 
devices per staff member. 

2. While the Chancellor who established the fund is no longer in 
office on our campus, this fund has been successful enough that 
when our three and one half years have expired the current 
Chancellor could reclaim a sizeable portion of the original 
investment and the fund would still have some purchasing power. 

3. The departments utilizing this fund have been able to upgrade 
their office equipment configuration without requesting addi- 
tional funding and not one of the borrowing departments have 
submitted a request fir funds to purchase additional Personal 
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Computers from campus special interest funds. 

Since the inceptior of this program, our campus administrative 
users have had two options for purchasing departmental computers. The 
first option (specially funded, one-time purchases), has the advantage 
of utilizing one-time appropriations and does not create a permanent 
commitment to the campus budget. It also provides the potential for a 
greater number of devices to be purchased in a short period of time. 
However, this option has the distinct disadvantage of not addressing 
the long term needs of the departments. This satisfies short term 
needs only. In the long run the departments so funded will return to 
the funding office again ... and again ... and again. They are 
created as parasites to the campus special appropriation fund- . 
Potentially, they may never have their equipment configuration modi- 
fied again. 

The self funded loan program provides a slower equipment growth 
path than the special funding approach. It also means r* depart- 
ment's budget is potentially endangered in years where campus budgets 
are reduced. The directors are potentially faced with the problem of 
how to pay for their equipment should they have their budgets reduced. 
However, the loan fund approach means the department has an avenue to 
upgrade their equipment in an orderly fashion over the years. They 
can creatively manage their departmental budgets by the judicious use 
of this fund. This program provides a much healthier environment for 
the campus budget as a whole. 

In weighing the pros and cons of the two approaches, it is my con- 
tention the advantages of the self funded loan program substantially 
outweigh those of the one-time appropriations. There is a sense of 
risk involved in that the director must gamble the departmental budget 
will not be reduced during the next forty-two months. However, the 
alternative approach presents the risk that funds will be available in 
the future to fund additional purchases. This latter approach relies 
totally on the good fortune that extra funds become available when the 
department needs them and that some person of relevance on the campus 
will be benevolent enough to grant the department the money the next 
time. It creates a continual line of people asking for special fund- 
ing favors from key campus administrators. Universities simply can 
not operate with a yearly line of administrators requestirg special 
funding favors like indigent in a bread line. Campus budgets must be 
properly planned and judiciously administered. However, departmental 
equipment needs must also be addressed if the campus is to keep 
abreast of the increasing work demands from internal and external 
sources. With an initial variable amount of one-time funds committed 
from the campus, the loan fund approach provides for a better managed 
equipment purchase policy and allows the University the potential to 
recover the loan with time. The self funded loan program is an 
investment in the future and one which creates a more stable budget 
situation for time to come. 
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